Archive for the ‘Agile’ Category

Agile is not a another project management practice

Monday, January 18, 2016
posted by daveb

Agile should not be thought of as another project management practice, like an alternative to Prince II. Its a fundamental rethink of 20th century management thinking (mass production / economies of scale, efficiency, scientific management (Taylorism), planning, control, hierarchy and fixed roles) for the 21st century, where application of creativity + knowledge and empiricism (feedback from actual experimentation) are coming forward as the keys to success in a complex and chaotic environment of constant change.

The very idea that there needs to be a fixed scope “Project” in order to create value is under threat. If we can produce value in excess of costs (including opportunity costs), then why would we stop at some predetermined future point (project delivery date)? You’d surely keep going, unless of course you are not producing value in excess of costs, in which case why would you start?

In this sense Agile (+Lean) is about building the “manufacturing” lines of the future where it is not physical products that we are producing, but this ephemeral thing called customer value. A manufacturing line is nothing like a “Project” – it produces value as long as customers are buying, and this is what Agile/Lean is really about.

Agile success is to put people over process

Monday, December 21, 2015
posted by daveb

As an industry, we have tried just about every method imaginable to deliver software. For every methodology that claims higher success rates it’s easy to find counter examples where the same methodology has been a failure.

I think what The Manifesto has done well is to point out that the things successful projects have in common are not in their method, but a set of very people-centric values and principles. Basically the underlying message in The Manifesto is that people matter more than process.

We need to stop talking about people as “resources”, and see them as individuals with character, intelligence, and a desire to make a contribution. We need to collaborate, communicate, bring customers and developers together, trust one another, allow experimentation, mistakes and therefore learning to take place. Allow autonomy, mastery and purpose and great things can happen.

Kanban Release Train

Monday, December 21, 2015
posted by daveb

Kanban is an ideal candidate to use with a “Release Train”. The Release Train works like a freight train that leaves every week at the same time. The user stories that are tested and ready to ship go on the train and get delivered. If a story is not quite ready we don’t work overtime nor do we change the ‘train’ schedule, we just ship whatever is ready to ship at that time, and if something misses the train there’s another one next week. Occasionally a ‘special’ train runs between the normal scheduled times because there is something of value to deliver.

Some stakeholders/customers may want to know exactly when a particular feature will ship and the down side of this approach is we don’t really make such promises. What we do though, is to build trust – stakeholders don’t tend to hover about asking what the team is working on when quality software is shipping on a regular basis.

This approach is based on the idea of Optimizing the Flow of Value to the business/customer. If we deliver to the customer feature B instead of feature A this week, they still get to see a stream of value flowing their way, and that is something that makes customers happy.

How do you measure the success of an Agile transformation?

Wednesday, June 17, 2015
posted by daveb

If there is a measurable definition of what Agile is, Cycle Time is it. Cycle Time is Agile distilled down to it’s very essence, with all the sentiment stripped away. To be Agile is to be responsive. Responsiveness means keeping up with the business, because if you are not keeping up, you are lagging further and further behind.

If I could choose just one measurement of Agile success (and it’s probably a good idea to have just one measure) I’d choose Cycle Time – that is time (in days) to turn a request or requirement into delivered business value (i.e. in production).

This is a very objective measure that is hard to kid yourself on. It’s also easy to measure, and it has direct meaning to stakeholders, business users/customers and team members alike.

So to test your success in becoming more Agile (whatever that means) test your Cycle Time before and after your transformation. This is easy enough to do – take a look at how long your average feature request took from inception to production before and after your transformation.

A Brief History of Agile

Monday, June 8, 2015
posted by daveb

Dozens of great books have been written around product and software development with lean/agile and related concepts over the last 50 years or so. While Agile is still young and evolving rapidly (bear in mind the term Agile was only coined in 2001) Lean and related concepts like the Theory of Constraints pre-date that term by decades. The Agile Manifesto was not the invention of iterative, business-focused development processes, it was just a milestone in its evolution towards mainstream adoption in software development. Very seldom have I seen an online resource even mention this fact – I guess the Internet believes history started in around 2000!

A small, random scattering of books to get some history on Agile and some insight into the origins of Lean and Theory of Constraints:

The Toyota Way
The Goal (Goldratt) 
The Mythical Man Month (Brooks) 
Extreme Programming Explained (Beck)
Lean Software Development (Poppendieck)
The Phoenix Project
Toyota Kata (Rother)
Peopleware (deMarco)
The Lean Startup

Hopefully some of these will lead you to deeper insight than online resources and get you past the hyperbole of Agile, towards seeing the 50+ years of solid evidence that supports its underlying hypothesis.

What is the biggest weakness of Agile?

Monday, May 4, 2015
posted by daveb

Agile, as in The Agile Manifesto (http://agilemanifesto.org/) is a very elegant way to express the learnings of many software experts over many years. The Agile Manifesto is a kind of declaration by leading software experts that there is another way to think about software development other than classic waterfall based, documentation / process heavy methodologies that tend to see people only as resources. While these experts don’t attempt to put forward a single recommended methodology, they do agree on the principles of the Manifesto, and indeed they coined the term “Agile”.

The Agile Manifesto hints at what Agile is by comparing the Agile way to the traditional way – “Individuals and interactions over processes and tools” for example. If you haven’t heard of the Agile Manifesto, chances are you’ve picked up some highly distorted definition of Agile, such as “Agile means no documentation” or “Agile means Scrum” or “Agile means iterations”. The Agile Manifesto says nothing of the sort.

So to respond to the question “What’s the biggest weakness with Agile?” we have to first be clear about what we mean by Agile. Ideally, we’d use the definition from The Agile Manifesto, but unfortunately the term Agile has become very overloaded, and has been mis-applied and widely misunderstood. The real weakness with “Agile” (in the sense its commonly used today) is the very word itself! Its almost unusable due to its many interpretations, connotations and so on.

For example, if you are trying to convince your organisation that it could benefit from Agile, its probably safer to avoid the term altogether than to risk those that have a definition of Agile in mind misunderstanding you completely.

Scrum in a BAU environment?

Monday, March 16, 2015
posted by daveb

Allow me to share a question, and my response to it on Linked-In’s Agile Coaching group.

Q:

Do you have any ideas or suggestions on how to improve the team focus while the Scrum (Ops) team works on several changes that sometimes don’t have a relationship?

Context: A mainframe environment of >6500 COBOL programmes where several highly complex regulations are gathered in one system.

A:

We have a very similar problem – one Product Backlog, one Scrum Team but the work that some team members do has little to no impact on what other team members do, to the point where they have independent test/release cycles. There’s probably 3-4 separate sub-teams, sometimes with overlapping resources, working on separate products that occasionally interact.

In Scrum terms, Scrum of Scrums is the advice on how to scale Scrum. This may be of benefit to you if you have say > 20 people involved, but for us with 9, it seems like too much ceremony.

I think there is perhaps an absence of good advice from Scrum around how to run Scrum with a small team & a diverse range of products. Scrum can still work, but there’s more waste in the form of exposure to communications that have no bearing on your work.

I would question whether Scrum is the right fit. Scrum has a sweet spot that is around complex (single) product development efforts with team(s) of 3-9 members, where much of the work is in-sourced, and the team is co-located.

It may also be worth looking at Kanban which has its sweet spot in product maintenance and support, because, chances are, if you have a small team and a diverse product portfolio to manage, you are in BAU mode.