Posts Tagged ‘Alan Shalloway’
Balancing Agile – Guest Post by Alan Shalloway
A fascinating difference exists between Agile and Business Service Management (BSM). Agile emphasizes continuous flow of value to the customer. In contrast, BSM focuses on the business – it aligns the deliverables of IT to the enterprise’s business goals. Subtle that the difference might be, the two methods evolved along quite different lines in spite of the common denominator – dealing with software.
In this guest post, Alan Shalloway – Founder and CEO of NetObjectives – discusses the implications of focusing on the business as distinct from focusing on the customer. His discussion is part of a few thought-provoking threads he weaves around the Agile Manifesto. Alan perceives the Manifesto a product of the times. He thinks aloud whether today’s circumstances require a revised manifesto.
Alan is a man of passion. While I do not always agree with him, I have a lot of respect for his quest to find the deeper truths. Furthermore, I always learn from him. Whether you agree or disagree with the opinion Alan articulates in this post, “listening” to his thoughts is well worth your time.
Here is Alan:
The Agile Manifesto was a watershed event that has forever changed the landscape of software development. So profound a positive impact of it has had, that few challenge whether it was actually correct. Manifestos are often a statement in reaction to something prevalent that needs changing. This makes them very topical and temporal – and the exact intention needs to be restated when the landscape against which it was drawn has changed. The Agile Manifesto[1] states:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.”At the time of its edict, this was profound and well stated. Too many software teams were:
- Following a process dictated to them from outside their team
- Managing according to an extensive set of artifacts that recorded where they supposedly were well before software existed
- Were given a set of requirements to meet with little opportunity to discuss real needs (note, points 3 and 4 in the manifesto address this point in two ways – first recognizing that customer collaboration is necessary to discover their true needs and second that it is essential to take advantage of newly discovered information)
The manifesto represented a new paradigm from which to work – one in which the team would have better control over its destiny and where it was recognized that one had to make incremental, iterative movement towards one’s goals – both in discovering the true goal and in implementing it.
Unfortunately, the perspective from which the manifesto was created, or at least the methods which first followed the manifesto, have been extremely team centric. Not a surprise, given the paradigm at the time gave development teams too little say in their own methods. The impact of this has been, not surprisingly, success at the teams and difficult beyond the team. It is almost axiomatic now that companies will have successful team pilots only to bog down in their enterprise agile adoption efforts or even revert back to earlier methods.
I say “not surprisingly” because several things have been left out of the agile manifesto. These are:
- The role of management
- The role of process
- The role of planning
- And indirectly, the role of guiding principles
It could also be said that the driver for agile development is misplaced. I do not believe “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This makes software groups customer driven, not business driven.
There is a subtle, but important difference. Basically, conscious or not, the Agile Manifesto is driven with a team-centric view of satisfying customers – business and management play mostly secondary roles. Unfortunately, there is a significant difference between customer driven and business driven (see the figure entitled Alignment with Vision of Business to the right). This is not apparent at the team level (the team is supposed to satisfy the customer). But definitely at the business level. Not surprising, however, since the manifesto is a team perspective it states things in terms of customer value.
Ironically, it is the over-focus on the team, however, that is robbing teams of one of their greatest tools. Clearly any method must have respecting people and providing those doing the work the ability to choose how they do their work. But this does not mean that process isn’t essential or that attending to certain laws of software development is optional. Rather it means that process can’t be imposed on teams since to do so would both rob them of respect and almost certainly be the wrong way to do things – who knows more about how to get work done than the people doing the work themselves?
But “Individuals over process” as the first line has come to be called, makes it sound like people are it. I do not think so – and I think this mindset has caused a lot of damage in many ways.
There is great evidence that the best approach is not merely get smart people onto a team and have them figure out how to solve their problems. They must be properly equipped to do so. Just being smart doesn’t mean you can solve the challenges facing you. This should be readily apparent, but in many ways, the Agile community has mostly ignored it. Actually, there is not really an Agile community any more – there are factions that have significantly different beliefs. For example, XP has long recognized the need for technical practices in Agile while the Scrum community is only just starting to get into what these are.
However, except for the Lean/Kanban community, few Agilists seem to espouse discovering and following the laws of product development flow (or even recognize their existence). This, in my mind, has led to the low rate of success in scaling Scrum to the enterprise*[2]. Ironically, it is the over-focus on people that leads many in the Scrum community to assert this lack of success is a lack willingness to take the effort to improve. This is not surprising – if it’s up to the team to succeed, then when they don’t it must be something wrong with the team or their management when they fail. I think not. I think it is the lack of understanding of the principles of software development flow.
These laws are not new. Don Reinertsen, in his iconic book Managing the Design Factory lays out much of the rules of product development. His more recent book The Principles of Product Development Flow: Second Generation Lean Product Development he lays out 175 of these principles.
To me, true respect for people means that one must equip them with what they need to get their job done. Our thinking in the Agile community should change from “People over process” to one of “People times process.[3]” This phrase emphasizes that if either are low, you get a low productivity. Process does not ensure success. But a poor process requires heroes to succeed. We’d like good, motivated, well-intentioned people to be able to succeed.
Our new agile perspective needs to include an understanding of what teams need to know to do their work. This opens up a role for managers to actively help teams get their job done and to coach them when they have challenges or lose their way. While I will always be thankful for the Agile Manifesto, I am looking for a Business Agile Manifesto that will expand the focus from the team to the entire enterprise.
Footnotes:
[1] http://www.agilemanifesto.org
[2] Ken Schwaber, iconic leader of the Scrum community has said that “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”
[3] I first heard this from Don Reinertsen. Before that I used to say “People plus process.”
The Mojo of Innovation Games
This post is a shameless plug for Innovation Games. Shameless that it might be, it is grounded in the hands-on experience I acquired as a participant in Luke Hohmann’s workshop on the subject last week. Colleagues Ken Collier, Alan Shalloway and Michele Sliger took the workshop together with me.
While Innovation Games had been conceived, implemented and published by Luke more than 4 years ago, the contemporary on-line implementation breaks new grounds in three important ways:
- It ties in ideation, requirements management and software project management in a seamless fashion. (Stay tuned for exciting announcements on the subject in a couple of months).
- It gets over the “too much data” barrier of the paper-based version of the game. Data capture is largely automated now. Data analysis tools are forthcoming.
- It gets over the “across the pond” obstacle. You can play Innovation Games to your heart’s content no matter how geographically dispersed your teams might be.
Not bad for three guys and a dog. Actually, I don’t even know whether they can afford a dog. These guys operate on passion, craftsmanship and mojo…
Postscript: If you know Luke, you already know what I mean by “the Luke mojo.” If you don’t, may I suggest you get to know him. A convenient opportunity might be the forthcoming Agile Roots 2010 conference – the organizers are speaking with Luke about delivering a keynote presentation literally as I write this post.
John Heintz on the Lean & Kanban 2009 Conference
Colleague John Heintz has kindly compiled the summary below for the benefit of readers of The Agile Executive. John is well known to Agile Austin folks as well as to out-of-town/state companies to which he consults through his company. You can get a glimpse of his Agile/Lean thinking by reading his blog.
Here is John’s summary of the conference:
The Lean Kanban conference last week in Miami was astounding. David Anderson did a fantastic job, and everyone who contributed had great presentations.
I am humbled and emboldened at the same time. I’ve been involved in Agile since 1999 and Lean since 2004, so I thought this was going to be familiar to me, old hat.
Here’s my confession: I’ve pretty much ignored Kanban, writing it off as just slightly different than what good XP or Scrum teams practice anyway.
Wow, those small differences make a huge impact. I am very glad I decided to go to the conference, some internal hunch finally winning.
Here’s what I thought Kanban was before last week:
- A Big Visible Board
- A Prioritized Backlog
- Close communication, minimizing hand-offs
- Rules about cards on the wall
No Iteration/Sprint boundaries (I’m thinking more efficient but maybe losing something important…)
That’s all well and good and true enough. Easy to justify writing it all off with “I already know enough to help teams make a big difference”. In fact, Kanban can be boiled down to one single rule:
- Limit the number of things in work to a fixed number.
But, if that’s all there is too it, why then did I hear things like these:
- Kanban is easier to introduce to teams than Agile/Scrum/XP
- “People who never say anything were offering ideas” (I’m pretty sure I heard this three time the first day…)
- The team felt comfortable dropping estimates/retrospectives/standup questions/…
Wait, you say, this was the first conference and obviously full early adopters! Of course people are going to succeed because they self-selected for success. Good point, but that’s not everything that’s here. For example, Chris Shinkle’s presentation was a case study of rolling out Kanban to many teams who hadn’t asked for Kanban.
So between furiously scratching down notes[1], listening and tweeting[2], I started to think to myself:
- Why does this make such a difference?
- Easier to create thinking and reflective teams! Isn’t that cultural change?
I had the pleasure of wrestling this “why” question out with several people, especially Alan Shalloway.
The first answers people gave me were entirely unsatisfying:
- David Anderson’s reply tweet: “Kanban is easier than Scrum because you don’t change any roles or workflow and you don’t teach new practices.”
- Alan Shalloway first response: “Kanban cuts out the noise and reduces thrashing.”
Sure, sure, but none of those (good) things seem likely to create: cultural change, engaged teams, or reflective individuals. Those answers are technical, details, and generally not the “emotionally” important things needed for change. Mind you, I’m not really well versed in cultural or emotional change, but being the stubborn person I am, I kept digging.
Here’s where Alan and I got, please add any insights[3]:
- My hypothesis: Kanban has concrete reflective tools: like “should WIP be 4 or 5?”. Very reflective, but not very abstract or hand-wavy. People can’t often use abstract reflective tools like Retrospectives.
- Paraphrasing Alan Shalloway: Kanban reduces the fear of committing to a per story estimate – a significant risk in some teams. Less fear can lead to cultural change.
- (not sure who): Kanban changes the focus away from blaming an individual to examining why stuff is stuck on the board. (I hear Deming…)
—-
On to the actual trip report. Here is an abbreviated transcription of the proceedings of the conference. (Very abbreviated!)
- Alan Shalloway started the conference off with no small announcement: the formation of the Lean Software and Systems Consortium. He also mentions that this consortium will be creating a body of knowledge and promoting a distributed certification process. Certifications will be a very interesting topic, my initial reaction was negative. Now I’m just skeptical 😉 I’ve got a hunch that TWI, a hidden influence of Lean, may hold some of the secrets for a successful certification method. We’ll see how this plays out.
- Dean Leffingwell gave a keynote on a Lean and Scalable Requirements Model for Agile Enterprises. Very clear from executives down to team activity: maps from Themes to Epics to Features to Stories. This immediately cleared up some questions I and a client were having. My favorite quote: “If you don’t know hot to get the story out of the iteration – don’t let it in” referring to acceptance tests.
- Peter Middleton presented material from “Lean Software Strategies“, co-authored by James Sutton who presented next. Peter is a professor at Queen’s University in Belfast and was the first person to really talk about the people issues. Much of what Peter related was how various practices caused people problems: recruiting and training goals (10 per week) would require recruiters and trainers to push even unqualified people into the company. That led to poor service, high-turnover, and greater costs.
- James Sutton has a small personal goal: to save the middle class. His presentation did a good job ranging over various Lean and Systems thinking topics, connecting the dots to Agile. Key quote comparing Lean and Agile: “Getting Prepared” vs “Getting Started.“
- Sterling Mortensen presented a case study of introducing Lean into the Hewlett Packard printer development division. He said HP was already the “best of breed” and still became much more efficient and effective. My favorite quote: “Stop Starting, Start Finishing“. Sterling also said the “One” metric was continuous Flow. I’m not sure I understand that all the way; I’d been working under the assumption the One metric was customer to customer cycle time (from concept to cash.)
- Amit Rathore gave a personal case study of Lean in a start-up, http://runa.com. Amit showed many examples and talked really honestly about his experience. My favorite quote: “not released equals not done”.
- Corey Ladas presented on his book Scrumban and his experience at Corbis (with David Anderson) and other projects. I bought a copy of his book out of his backpack and made him sign it.
- Jean Tabaka presented a thoughtful presentation on Lean, learning, ignorance, and people. Her narrative helped me further realize how Lean, and Kanban, play into the personal issues of learning and reflecting.
- Alina Hsu presented a case study of using Lean to organize the work of procuring a COTS (commercial off-the-shelf) software solution, not development. She had some great things to say about how delays cause major cost overruns. One thing that reduced the delays she mentioned was to change how agreement was reached. The team defined consensus as “I can live with it”, with the rules 1) I won’t go into the hall and try to subvert it, and 2) I won’t lose any sleep. These definitions help teams make decisions faster and reduced waste.
- Alan Shalloway presented on a model for understanding Lean and moving it beyond Toyota. He organized all the various concepts down into Lean Science, Lean Management, and Lean Education. Connecting this back to the Lean SSC announcement in the morning he said the consortium working to create value in those three areas.
And that was just the first day. Did anybody mention the conference day started before 8am and lasted till after 6pm? Oh, and everyone was glued into the room.
- David Anderson presented a keynote on the principles and evolution of Kanban. So much information! You’ll have to read his presentation and see the video on InfoQ, but just to provide a fragment from each I wrote down:
- Principled recipe for success (including Balance Demand Against Throughput)
- Metrics (like WIP is a leading indicator)
- Agile Decision Filter questions
- Lean Decision Filter questions
- Kanban decouples input cadence, cycle time, release cadence
- Karl Scotland continued the detailed treatment of Kanban. Karl spoke about the Lean concept of Flow as expressed with Kanban – and even rename typical process steps to avoid any baggage with waterfall terminology. If you want to know more about how work actually gets done in a Kanban system, watch his presentation. His interesting names for for process steps are: Incubate, Illustrate, Instantiate, Demonstrate, Liquidate.
- Rob Hathaway presented a case study of his work building a game portal for a publishing business. He believed very strongly that teaching from principles (Value, Prioritization, WIP limits, Quality) led to success.
- Alisson Vale presented a tool… that enchanted everyone in the room. David Anderson himself said that Vale “has the highest maturity software team on the planet”. Now, tool support often isn’t the answer, and many teams get real value with a physical board – a tool isn’t a Silver Bullet. If a tool makes sense for you – this tool absolutely blew us away. I asked Alisson about buying or helping with the tool and he said they were considering open sourcing it! I offered my coding skills in extending it for my own clients to help reach that goal.
- Linda Cook presented a case study of using Kanban at the Motley Fool. Her presentation does a good job of showing how little is necessary to get a lot of value out of Kanban.
- Eric Landes gave a great case study about using Kanban in an IT development shop. His team went from struggling to turn requests around (41 days) to a rapid 9 day turn around. Again, his discussion of the team dynamics and reflection were interesting to how a tiny bit of Kanban can have a huge impact.
- Eric Willeke’s presentation was visually beautiful, but you’ll have to watch the InfoQ video to get the value out of it. It contained only two words in a quote bubble (from memory “Momma! Pirates!”) and was the backdrop for the story that he told. His story highlighted to me, again, that Agile doesn’t always stick but Kanban seems to.
- Chris Shinkle presented a multi-case study on rolling Kanban into a large software consultancy. Very interestingly, and contrary to much discussion before, Chris presented a practices first, principles later message. This again resonated strongly to me that Kanban practices are somehow special in encouraging people to reflect and reach for the principles.
- David Laribee presented an opinionated view on leadership and change using Lean. This quote stuck with me: “people support a world they help create”. His style of leading is to drive from “Values -> Practices -> Tools” and his presentation wove a story of Agile/Lean process change. Also, I really enjoyed his injecting reference to hardcore technologies: REST, Git and OSGi were fantastic to see in a Lean/Kanban presentation.
That was day two. I’d said we were all glued to the room before, now as I type this I realize our brains were coming a bit unglued at this point. Every presentation was top-notch, barely time for questions, breaks were cut short, and we came back for more as fast as we could. Oh, and apparently we collectively drank 2.5 times as much coffee as the hotel usually allocates for a group our size.
I’m not going to summarize the Open Space. Too many topics and changes in direction. You just had to be there 🙂
Cheers,
John Heintz[1] I used the first 25 pages of a brand new notebook… for a 2.5 day conference… Every session had an overwhelming amount of information, and I’m glad InfoQ recorded video.
[2] My twitter account is http://twitter.com/jheintz, and you can follow everyone’s conference coverage at http://twitter.com/#search?q=%23lk2009.
[3] I’m going to keep following up on this topic in my personal blog: http://johnheintz.blogspot.com
The Agile Executive 