18 October 2017


You've probably heard of the 7Ps, Proper Prior Preparation Prevents Piss Poor Performance. What does that mean in the context of an agile team?

I often use the imperfect analogy of an automobile to describe an agile development team. Simply, the tires are the production system, the drive train is dev-ops, and the engine is the development team. The product owner/architect/tech-lead are the fuel delivery system to that team and stakeholders/business people are the gas-tank. When they all work together the car runs soothly down the track. 

Here's the thing. If the product owner and architect aren't filtering the fuel before feeding it to the team, they aren't doing all of their job. It isn't just about pumping fuel from the tank to the developers, its also about straining out the gunk that might be in the fuel as well as distributing that work somewhat evenly across the team members. That is, making sure the fuel is clean and that every cylinder gets some of it. 

I'm going to just use Product Owner as a proxy for anyone providing requirements directly to the team (Architects, Tech Leads, Engineering Leads, etc. all count as Product Owners in this scenario).

When a product owner shows up with a story, it needs to be fully digested and understood by the product owner. It needs to include answers to questions like For Whom? Why? When? and What? One essential component is of understanding that needs to be present is, what. 

What means, what does this story do or accomplish and in understanding that we need some of the How, but not in a technical sense. That is, we don't need the Product Owner to provide the algorithm or a design document, but rather, How do you do the math? 

An example; Calculate the percentage of ripe fruit on sale for a given date. Sounds simple enough, look in the inventory for all the fruit available for sale who's status is ripe on a given date and the total count of fruit available and do some math. But in real life that might not be a simple query. For example, we may only have available a total amount of fruit, ever. How do we do the math now? Do we deduct the entire historical record of fruit sold from total count of fruit to get fruit available? Then how do we determine ripe fruit? Same way? 

This space of understanding can be solved without the business getting involved. The developers are more than smart enough to figure out a way to get an answer, but it's quite possible it won't be the right one. 

So somewhere in the preparation of the card the Product Owner should have discovered this and documented it. This isn't about stealing the thunder of the brilliant developer and it isn't about providing a how; this is about communicating what is expected. That is, what ratio is the business trying to show. 

17 October 2017


Hello again. I was sick over the weekend and failed to get a post out on Monday. That has taken me on a tangent to thinking about delays.

So one of my projects is now effectively delayed because I was unavailable. I'm sure we will recover, I just need to make up for that keyboard time and we'll be back on track. But this impacts our delivery date. I now need to work some more hours durning the week to make up the difference.

Similarly, on another project we're running into a problem of stakeholder availability. A few of the stories we are working on have come to a halt because we don't have a complete understanding of the business needs or the technical details. Each of those stories has been delayed. An interesting side effect of this is that we are stretching our WIP limit because we're picking up other work to fill the gap. 

In the first case we have a pretty simple case of needing to just rearrange the only work schedule because of a lack of resources to do the work. It's a simple solve. Given more staff we could have just swapped in another developer to do that work. Since we don't have more staff, we just shift the schedule.

In the second case we have plenty of worker resources. The issue here is a lack of executable work, leaving worker resources idle. Whats interesting to me is that, as a result of having too many workers and blocked cards do to incomplete specs, we have pulled more work into the system to prevent idleness. As a consequence the load on the team, in terms of things to keep track of/manage is increased, but the productivity is unchanged as best and possible decreased if the cards remain blocked.

So this second case is whats most interesting to me. In an attempt to keep all resources utilized we add work to the In Progress list and mark other work blocked. In particular, because we're waiting on an external resource (Stakeholder) to answer a question. Back in the day we would have asked our product owner, who was sitting in the room, to help us get the answer and we would have actively pursued that answer until it was either found or determined to be unanswerable. In the later case we would discard all the work and move on to another card. 

We seem to have adopted a 'wait for the answer' posture, one that is even passive. That to me shouldn't be acceptable. Rather, we should work to engage the stakeholder in a manner that encourages them to give up the goods on demand OR have given it up in advance. 

In advance is a problem though. In my Shangri-La the product owner is in the room and ready to answer questions at all times, no advanced planning necessary; but thats not reality. In reality, where we actually live, the product owner/tech-lead team have looked at, though through, and triaged all the cards before the development team sees them. They have at least a minimum amount of information ready and available to answer the teams questions. [I'm not saying that info is necessarily on the cards, just that its readily available]

While this doesn't conform exactly to the 'A card is a promise for a conversation' ideal, if a card could be a proxy for pre-digested (by the PO/TL pair) answers to expected/common questions it will impart efficiency into the process of delivering the story.

I recognize that this is similar to the Definition of Ready that some teams use, but I see a difference in how it is applied. The DoR is typically applied as a gate keeper on the 'Ready' column for the team; if the check boxes aren't checked then the card can't be added. Rarely, if ever, do I see the Product Owner or Tech Lead using the DoR as a check list for preparing work; and when I have it's been an awful disaster. 

Somewhere between the DoR and a card with two or three words on it is an place where the Product Owner and the Tech Lead understand enough of the details of a card that they can answer reasonable questions about it without having to wait for an external stakeholder and/or a series of spikes to be completed. 

I'm way over my length goal here, so I'll save my thoughts on the realistic solution to this problem for another post. 

13 October 2017

Criticism -- You're language is no good

So I was reading an article the other day, suggested by someone I work with, and it had some very disparaging things to say about Java. 

It got me thinking, why does Java have a reputation for being overly verbose and full of interfaces and such. C# seems to have a similar reputation. 

But heres the thing, it's not the language that's doing all that. Its the frameworks, the books, and the people. The language doesn't care.

I have to agree that Java has some overhead involved just by its very nature, but it is mostly easy to use otherwise. Sure, it's statically typed and has some limitations (though gradually many of those are going away) but the language doesn't force you into creating a bunch of interfaces and having super complex structures to get things done. 

So why do we keep beating up on the language? Why, instead, are we not critical of the people who write the code like that? And the designers who create frameworks that force us to write code like that. 

I'll admit, I've written some insanely complicated Java in my time, but I learned that I wasn't getting any advantage from doing so and I quit doing it. Now, for the most part, my Java is pretty clean and simple. At least as much as I can make it be within the limitations of the language. 

I have read a fair amount of open source code. Not as much as others, but certainly my fair share. I think some of the code out there is way over complicated. Sometimes its just down right ridiculous. And it doesn't matter if it's Java or Python or Ruby or anything else. So why does Java (or C#) get the bad rap? 

I'm heading somewhere with this line of thinking, but I'm not sure where yet. I've been trying to get this much out of my head for 3 days. It's hard to do without sounding like a lunatic.

More later I hope. 

11 October 2017


So getting back into the blogging rhythm is proving challenge. I'm going to try to do the 3x a week thing again, but I might be a bit uneven on the delivery while I get back into it. Please be patient, I'm just rearranging my self a bit too much right now, but I'll get there. 


Apropos nothing and everything at the same time, Dogma is BAD.

Blind adherence to a method or practice leads to stagnation and complacence. 

Right at the moment I'm working on learning and understanding some subtleties of using functions as first class objects and how that impacts. What I'm looking for is the balance point between too much and too little of this approach. 

I'm doing this first because I want to learn something; something I hope will improve my skills as a developer. Secondly, in conversation about exactly this it was difficult to articulate how much of this should and should not be done. 

After that discussion a few links to various sources were provided and I started digging into this idea. Coming from a C++/Java background originally I'd bought into the idea that everything is an object, if it isn't an object it shouldn't exist (with all the necessary caveats necessary to digest C++ and Java). 

So, if I accept that that isn't necessarily true (reject dogma) then I need to embrace this new approach. First I need to really understand it and how it works, but then I need to really get into the subtle parts so I can speak coherently about it. 

This is just one example of the whole dogma thing. You've heard me speak about 'creating cards' and 'you have to because the process says so' etc. elsewhere. The same stuff applies to things like OOD and idiomatic Python or 'Standard Java'. 

All of this has inspired a bunch of other thoughts I hope to share soon.

09 October 2017


Welcome back! I missed you.

I had to take a short break from blogging. I got a little overwhelmed with too many things and blogging fell to the wayside.

So I've been thinking about trust for a couple days now and its role in the team room and in collaborations in general. I'm not going to role out a bunch of quips about trust here, I want to talk about it's value though.

Without trust in a team there can be some serious consequences. A simple consequence is that when team members don't trust each other they can burn a lot of energy second guessing each others work. Related to that, individuals can burn a lot of energy speculating about what their team mates are doing.

Thats a lot of wasted energy.

So how do you develop trust in a team? I think there are a lot of ways, and I won't claim to know them all. My usual reply is 'drinking!'. But more seriously, it is important to develop a human connection between team members. That can be as easy as asking how someone is doing, what they did over the weekend, or if they need some help. Just being a human being is necessary, and will eventually lead to trust.

There is another critical component to developing trust. You have to listen to each other. When I say listen, I don't mean wait for the other person to stop talking, that's being polite, I mean actually hear and process what they have said. 

We don't have to agree all the time, and we don't have to have groupthink, but if we aren't even allowing alternate opinions to be voiced, in addition to showing a lack of respect, we are fostering a lack of trust. Consider the view point of the speaker; when you ignore or shutdown their words you are telling them you don't care about what they have to say -- you are telling them you don't trust them. Now ask, why should they trust you?

18 September 2017

TDD is development

Apropos very little, in a recent conversation it was suggested that testing is waste from the perspective of the business. My immediate reaction was visceral opposition to that line of thinking. 

After some consideration it occurs to me that the assertion that Testing is Waste must be wholly incorrect. Here's how I got there.

First, if I ask you to build me a Flux Capacitor, how do I know I have one unless I test it? That is, testing is the validation that tells me as a product owner that I have received what I asked for. No waste there.

Second, if I'm making a Flux Capacitor I must have some means of knowing that what I've built does what I want it to do. I'll have to test the device to see if it qualifies as a Flux Capacitor. 

So, in order to build the Flux Capacitor, the engineer building it must conduct some tests to ensure that the thing built behaves like a Flux Capacitor. In order to receive a Flux Capacitor, as a product owner, I must conduct some tests to verify that the device I've been given is a Flux Capacitor. 

Therefore, testing isn't a waste, it is a necessity. 

15 September 2017

Idioms, Standards, and Conventions

Finally, a blog with more than a one word title.

Today we had some conversation about standards on our team. I think it was a good conversation. It got me thinking about idiomatic use of platforms. 

Did you know (technically) idioms are not standards? 

I'm all for idiomatic use of tools, platforms, etc. Doing it like others is a good thing. Convention over configuration, etc. etc.

That said, there are occasions where you need a standard. Just because your agile doesn't mean you can't have some kind of rigor. 

It is important for every team to figure out what standards they need, and each team is bound to be a bit different. It's also important to follow the standards if you have them. Having them and not following them is a bit of a waste.

Lastly, like all other things, you should periodically question why you have a standard and if it is still appropriate and/or needs to be changed, updated, or removed. As we learn more about what we're doing our needs usually change and sometimes our standards need to change with them.