Agility Unleashed
I just finished custom designing an agile approach to rapid innovation for Artificial Intelligence exploration and deployment. It’s not Scrum or XP and it’s not Kanban, but it embodies the spirit of agility and it borrows a little from each of these along with some new innovations. This is the third custom methodology I have created for a client. I am looking forward to seeing how it works for them and how it evolves and how quickly it adapts.
What I have noticed for a long time is that agile methods, when done right, where they embody the spirit of agile, work very well. On the other hand, fixed frameworks installed in a cookie-cutter way and imposed on people always fails, or at least, always falls far short of delivering on the potential of a company or division or department. More often than not, it also produces misery.
Funny about that. How can a philosophy whose first and most important value is people over process do that? Easy. It got imposed and installed as process over people.
The company I did this last job for has been doing Scrum and Kanban well for a dozen years. I know. I brought both of them there in the first place. While they have been doing well, they also realized that they needed something a little different than their normal way of doing things for the challenge at hand.
To help them evolve their new framework, I gave them some of the guidelines that I used to create it. The guidelines are basic to lean and agile and yet they are often lost when focus is too much on the mechanics. It is hard for people to let go of the way they’ve been doing things that seemed to have worked for them, yet I call upon them to reexamine everything.
Here are the guidelines I gave them that informed my design. This was particular to their situation as I saw it, but you might find some of this useful:
Lean and Agile Good Practice
In the world of lean/agile, there is a lot of useful knowledge that can be applied to the problem at hand - how to organize around rapid innovation of AI. Sometimes it’s a temptation to apply techniques that worked in different situations to the current one. There’s nothing wrong with that as long as we critically reexamine everything with respect to the current context.
I submit that the following ideas are good ones:
Minimize wait-states and the latency between steps.
Maximize developer focus (being in the zone) so minimize interruptions to the people doing the actual work.
Minimize the time people are in meetings where they are not needed or only needed part of the time.
Minimize meetings in general - sometimes the objective of a meeting can be met in another way (like with an information radiator).
Stop starting and start finishing - focus on getting work done versus having work in progress.
By lean standards, all work in progress is waste. To reduce waste, defer work (like design work) to the last responsible moment (like when you are actually going to build it). ***This implies that any design work done in a refinement meeting is wasteful (so keep it to a minimum). You may not actually do that work or the situation may have changed between the initial up-front work and the time of pulling the work item into development.
Smaller teams move faster.
Eliminate bottlenecks and constraints as much as possible.
Maximizing work not done reduces waste. [That’s directly from the Manifesto but important to say.]
Producing what people use is better than producing what people don’t use.
Developer enthusiasm is one of the top predictors of project success and speed.
Making work visible is essential for the situational awareness that allows for effective, self-directed decision-making.
The status and progress of work is best ascertained using techniques other than a status meeting.
Innovation and good ideas can come from anywhere. Welcome them. Invite them.
It’s People over Process. This implies that developers cannot be treated as order fillers on a factory line.
Autonomy (as defined by Daniel Pink in the book “Drive”) is important.
The more teams self-manage, the faster they will be. One just needs to set the guard rails.
Swarming is better than independent tasking. Teams acting as teams produce better results when they assume collective responsibility for the results.
This is not a compendium of good practices, just what they needed reminding of as they absorb my suggestions.
Lean and agile work if you apply the fundamental principles to your situation. Don’t throw out the baby with the bath water.
What do you think?