Sunday, September 28, 2014

Can we make a promise?

Well, can we?

There are some who do ‘waterfall’ (well, to be fair, something very roughly like the waterfall that Dr. Royce defined in 1970), and some of them seem to believe that we know enough early on, and change will be small enough for the rest of the effort, that we can promise a relatively precise date at the very beginning.  And reliably hit it.   And then, if we do not, they blame ‘scope creep.’

There are some in ‘agile’ (again, we must qualify it) who seem to think that change is always so large and we know so little up front, that we can never promise any release date for our product.  Not at the beginning, and not even along the way.

Of course, we have to agree that the dumbest day of the project is Day 0, at the very beginning.

Next, let us first recognize how important an early release date is.  It is very important to our customers, and it is often extremely important vis-a-vis competition and other factors.  If we release earlier (eg, on time), then the present value of the business value we will earn will be greater (assuming other things roughly equal).

So, clearly there is a great need to release earlier.  And, along with that, although arguably not as much in every case, a need to predict the release date earlier.  And with reasonable accuracy.

Can we do that?

The short answer is yes, to some degree.

In Agile, we can do that, in my opinion, somewhat better than we did in waterfall.  Which also means, still, not all that well on Day 0.  We still have problems in predicting the future.  We know the detailed requirements will change, in many ways and for several reasons.  We know both good and bad change will happen.  It does every time.  The only question is how much things will change.

Still, after some time and experience and learning, we can make some prediction.  And often, with a reasonable contingency, we can hit that date.

(I do not mean to suggest that the first attempt at predicting the date is accurate enough.  That itself is an important business decision — when do we feel we are accurate enough?  (after adding some contingency). Very good and difficult question.)

Can we predict ‘accurately enough’ every time?  Of course not.  And there are many reasons why.  Sometimes we get hit with the ‘Japanese tsunami’ of change.  A lot more change than we could have reasonably predicted.  And then, usually, other people will fully understand if we do not deliver on time.

In another scenario, it is often not one piece of change, but the accumulation of multiple changes that overwhelms us as a Team.  And, because it is not one big public change, but rather many factors, it is harder to understand from a distance.

Some situations are by nature more variable, subject to greater amounts of change (ex: subject to more learning about competition).

Still, even so, predicting, and using the information and learning we get from planning, can be very useful.  It can give us a better basis from which to learn more, in many dimensions.

Finally, one more factor that must be managed well (and often is not).

We need sustainable pace.

First, it is a moral issue.  We cannot treat people as slaves.  Second, we must have sustainable pace because it will make things better.  A pace that enables people to rest, and then, when they are working, to give their best creativity.  So that the innovation is more impressive.

So, what is the problem?  Well, we also know that people need some pressure, some challenge, to do their best work.  And we also know that many many teams, if the deadlines are tight and people say ‘go fast’, the Team often hears that as ‘cut corners.’  In other words, build technical debt.  Write sloppy code, let bugs in, do not document enough, do not refactor anything….and many more bad practices.

So, we the Team, we the Product Owners, we the managers, must be very careful in agreeing on dates and how we talk about this stuff.  Or you will quickly have a buggy ‘legacy’ system, and everyone will resign from over-work.

And it is hard.  You should (in my opinion), ask for dates and predictions.  And the Team needs a challenge.  But we must also talk about sustainable pace, about simplifying the work we do (smaller features), but NOT about cutting corners on quality.  Or maybe better said as ‘still, what we do build, it will be of good technical excellence.’

I will not talk here and now of how we keep our promises.  I have hinted already that breaking down the features and doing as little as necessary on the ‘big’ features is key.  Fixing impediments is key.  And identifying the minimum marketable feature set is key.  And hence, making the right trade-offs is key.  This includes cost-benefit trade-offs.

There is an art to doing the continuous research more effectively to make and revise ‘promises’.
And there is an art to working with the Team to change numerous factors so that we can improve the probability of keeping our promises.

People care about time.  Tempus fugit.

Is Scrum about spirit?

I hear people talk about Scrum quite a bit.  And I talk about Scrum.  Usually we are talking about the basics of Scrum, which sometimes seem so mundane.  Get a Team, make them a real Team, do the SM role well, do the PO role well, have some better meetings, build some artifacts, etc, etc.

But is Scrum all about these practicalities?  Is Scrum just the roles, the meetings and the artifacts?

I hate to say it, because I know it bothers some people to the point of offending them.  But there is a spirit about Scrum, and if you ignore it, you miss what is most important.

I often talk about Scrum-Butt.  “We do Scrum, but…”   Often this is really about how people can do Scrum and do it so poorly that they only get a 20% improvement (as  though in real life a 20% improvement were not huge).  But by not doing Scrum fully, they reduce the improvement they might get.  And we call this Scrum-Butt, from the phrase ‘we do Scrum, but…[we don’t do a Daily Scrum, etc, etc).’

And I talk about how, to avoid Scrum-Butt, the Team must have the values and principles of lean-agile-scrum embedded in ‘muscle memory.’  And so, I put a focus on the values and principles.

But there is a spirit about Scrum too.

I think Jeff Sutherland is in part talking about spirit when he says that ‘they must be having more fun – it they aren’t having more fun, they aren’t doing Scrum right.’

I think there are many aspects to the ‘spirit’ within Scrum.  In part you can see them through the rules or the values or the principles (and there are many more than just those articulated in the Agile Manifesto and the Agile Principles).

There is something magical and wonderful when a Team of 7 rights itself through self-organization, and becomes a unit that can accomplish great work.  And, without putting too fine a point on it, the spirit of the Team is clear, and one feels it is that energy, above all else, that gives them their power, and their effectiveness.  As a New Englander (which I am in part) does not know quite what to call that camaraderie, that sense of joint ownership, that happiness, but it feels almost as though the spirit of the Team makes itself known in these ways too.  One finds oneself caring about the others in the
Team, one finds greater respect, one allows each member to be more his true self, and yet that does not tear the Team apart, but rather brings them closer together as a Team.  If one were from another culture, one might almost say the team exhibits the characteristics of a higher love for each other, and for their customers.  But love is a word seldom used in New England except in connection with Hallmark cards, and then usually with a chuckle.  And to speak of agape and caritas sounds too much like some philosophy class, about which we must soon joke.

In any case, until you have been inside a really good team, and until you have observed a really good team from outside, I am not sure you can know what I mean.  And, more importantly, I do not think you can really understand Scrum,  until you have felt that spirit.

What is rather interesting about Scrum, I find, is that if one enters it with an open heart, and just does it, even does it only partially, it seems to me that Scrum fills you with its spirit.  And, as one consequence, you naturally care more for your teammates and more for your customers.  Or, so I find.

Your comments are welcome.

Monday, September 22, 2014

Impediments – Charlotte Sept 2014

The following impediments were identified:
  1. Egos
  2. No proper test environment
  3. Bad data
  4. Process failure
  5. external market
  6. Lack of coordination
  7. Unrealistic timeframe
  8. Change Mgmt
  9. Org changes
  10. Changes in technology
  11. Budget
  12. Customer communication (lack of)
  13. Too many defects
  14. Waterfall “hangover”
  15. No accountability
  16. Management interference
  17. Bad product owner
  18. Lack of structure
  19. Lack timeline
  20. Ru out of money
  21. Unclear scope & vision
  22. Change of strategy
  23. Testing
  24. Lack of buy-in
  25. No proper acceptance criteria
  26. Planning (lack of)
  27. Not following agile practices
  28. New technologies
  29. Lack of skill sets
  30. Poor requirements
  31. Scope creep
  32. Lack of clear goals
  33. Story (stories) not well defined
  34. Changing priorities
  35. Requirements change
  36. Bad arch
Some maybe redundant, but they were from several firms.
I am a strong advocate of a public impediment list.  And working the list, one item at a time.