Sunday, August 17, 2014

Think Backwards to Split Stories

Splitting stories through vertical slicing is something you’ve probably heard and are practicing.  Now you’re probably thinking “I’ve done that before, this is simple.”  If that were the case, many of the agile consultants would be out of the job.  It’s harder than you think to have the discipline to slice features up.  It’s also tough to be disciplined and make sure that ever iteration has multiple features in the iteration. 

Often times iterations become boxes of features – when planning the sprint the question asked is “what can you deliver in 2 weeks” as opposed to “what can you grow in 2 weeks”.  Creating two week feature boxes is encouraged by a lot of authors that talk about release themes – people misunderstand that to mean that sprints should be themed.  When push comes to shove the sprint is extended to meet the completion of the theme.  Sound familiar? 

Thinking in terms of a pull system rather than ‘pushing’ work into a sprint will go a long way.  I’ve had students that said their software is extremely complex and nothing can be produced for weeks on end.  Consider this – do you compile and check out what the code is doing only after the end of weeks – I hope not.

A 2 week sprint is 2 weeks of time, not an estimate of what the team thinks can be completed in 2 weeks which is then extended to accommodate the estimated features.  You’ve got to think backwards, that will help quite a bit.

Sunday, July 13, 2014

End of the line for a coach

I’ve been a consultant for quite a number of years, in both technical and managerial roles.  One thing I’ve noticed about being a business coach – the end of the engagement is very different technical engagements. 

When you’re a developer and the end of the engagement comes, it’s usually because some huge project is finishing up.  There’s a celebration and a sense of finality.  There’s usually a concrete deliverable and the project is moving into a new phase of routine operational maintenance.  It’s over and, hurray, you’ve done it.

When you’re a coach the end of the engagement is quite different.  The client no longer relies on you for understanding or your expertise.  It’s down right sad.  You begin to be less and less important until they come to you and say that they don’t need you any more.  Hopefully they end with a retainer for a certain period.  You don’t go out in a blaze of glory but tend to trickle out.  So sad.

I must say though, knowing that the client doesn’t need me any more is actually satisfying, despite knowing that I won’t be working with the teams any more.  Human nature makes it difficult to look at the positive in such a situation – the end of an era – but if you’re even in this situation, just consider where they were when you started.  They’re probably better off.

Sunday, June 8, 2014

Interview with Ken Schwaber Part 5

Part 5: 

Evidence Based Managment
Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 5 of 5, the last in the series.  Enjoy.

KS - I think some managers are not going to welcome this approach because they are only responsible for explaining why projects didnt deliver on time and being able to blame someone else. This is going to be really, really scary to a good number of managers who arent very confident in what they do. 

I think that when they all start looking at the metrics and start seeing what is really happening, it is going to be pretty interesting. One of the sneaky things in EBM and the agility path is the agility index (a rollup of the metrics).  This is the easiest metric to compare (between organizations) as a trend within your organization and thats pretty scary right there.  We also gather more data for comparisons between like organizations in the same industry sector.  All you need to do is put out a report out with inter-corporate metrics and have it show up in Forester and Gartner and other newspapers and youll start seeing a lot of interesting discussions.

The idea is appealing however once you start using it and it starts coming back on you that you have to do something to improve the organization.  And for EBM thats the hook; thats the trick thats in it. 

Sunday, May 18, 2014

Interview with Ken Schwaber Part 4

Part 4: 

Next big evolution of Scrum
Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 4 of 5.  Enjoy.

KS - For us I think the next big evolution is evidence based management (EBM) - to show the value of doing work one way or another.  Not only for businesses to see the value but if they dont act on the value it should be clear that they are doing things that are not beneficial to their corporation.

Evidence based management just says "heres some metrics we can use to see how we are doing" and these are things which I could take right into my management and show them.  It is appealing because is doesnt even start with the idea of change.  It simply starts with the thought that its really a good idea to try to measure what is going on. Its been a problem that management only sees IT as an expense that doesnt provide much value.  If we measure business value, we suddenly change the way we interact with upper management.  They think "this interesting, why dont we measure IT in terms of value and see how much value is actually being provided".  Now of course you cant do that in the absolute sense, you cant say "oh this is 17.4 oz of value", but you can start setting baselines so you can compare trends and predict based on our actions what will happening over time. 

Another problem is that agility has not been measured. Jeff and I seen over and over again a company getting really, really, good at agile and their management believing it is not doing any good.  The idea in EBM is that if you have measurements, just like scales have measurements and manufacturing has measurements, you can see the effects of change and agile.  You bring to management a new way to tell if they are continuing to get better or worse. 

Im hoping that between two thrusts this will work.  One thrust is that management hasnt measured IT or product development - ever. They have been under pressure to have a way of measuring so they can report to their CEO and EBM gives them an answer. The second thrust is that the measurements can spotlight their actions and hold management accountable to some degree of performance in the same way the rest of the organization is.  This raises transparency at the management level just like we have at the development level.

Sunday, April 27, 2014

Interview with Ken Schwaber Part 3

Part 3:

Threats to Agile
Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 3 of 5.  Enjoy.

KS - I think the biggest threat to agile adoption is peoples desire for certainty and their belief that somehow, if they can nail things down just a little better, they will have certainty.  You see that with SAFe and D.A.D. and even Kanban, which has more certainty than Scrum.  Even within Scrum there are conversations about how to get more predictability with velocity, more precision in sprint planning and trying to be more certain of what we are going to deliver at the end of the sprint.  All that is absolute contrary from the biggest idea in Scrum: lets use short cycles so we dont care about how much we create because we are going to find out very soon.  Middle management wants predictability so they still havent gotten on board because we havent clarified their role.

I heard a year ago at an ALM conference that one guy was giving a talk saying agile was a fad. He was talking about what the next biggest fad would be. That scared me because I think the basic thinking in Scum is to use empiricism to manage complexity.  If they view this thinking as a fad then it can swing back to “lets try to control this” and that’s a danger. 

Over the last 3 years I’ve seen everyone is coming up with a new way to make money off of agile and its not really thought through but just an application of old thinking to the agile movement.  They stand a good chance of crushing agile; of turning agile into a nice set of ideas that are honored in word but not in principal.