This is all too funny! Whilst the video is intended to be humorous, the pain of the “Agile Guy” maybe all too familiar for some. Agile changes many things we have become use to over many years – agile questions the status quo and challenges our muscle memory……..
I have been a fan of Mike Cohn and his latest book Succeeding with Agile: Software Development Using Scrum is another great book. He blends a good mix of theoretical and practical techniques drawn from his past experiences. This book doesn’t show you how the Scrum Framework works, but it is more of a cookbook of good practices and suggestions that you can help you succeed with Scrum. So if you are new to Scrum or looking for an introduction to Scrum I suggest you read some other sources first such as the Scrum Guide (by Schwaber and Sutherland) or the Scrum Primer (by Deemer, Benefield, Larman and Vodde) and then coming back to this book for tips and advice as you implement Scrum.
I was able to relate to some of Mike’s observations with my own experience and found myself nodding my head in agreement to some of his sections on ‘objections’ and various stories throughout the book. As a result, the book felt very personable as I felt like I have been there done that. He does offer some practical advice when dealing with the various ‘objections’ that you may encounter along the way. He also points out the challenges in adopting and transitioning to agile. The following is an important quote from the book:
I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.
A common theme throughout the book is that there is no ‘standard’ way of doing agile and that it must be adapted to the organizational context and project. He devotes a whole chapter, ‘ADAPTing to Scrum’ [Chapter 2] to this topic.
Although it is mainly centered on Scrum, Mike describes various other techniques and methods to produce a handbook that is thorough and complete for any Agile practitioner. Scattered throughout the book are real-world case studies drawn from the Mike’s experience helping many software organizations adopt Scrum, and ‘things to try now’ sections based on his advice offer practical, quick ways of coming up to speed fast. I really liked the chapters on New Roles [Chapter 7] and Changed Roles [Chapter 8] where he describes the 3 key Scrum roles but also identifies how the traditional roles changes to fit into an agile development framework.
I highly recommend reading this book as part of your Agile training, whether you are implementing Scrum for the first time or an experienced practitioner. It is an easy and good read.
Despite that we are still yet to finish the current scope of work for the Agile Initiatives, we are starting to discuss future items in our backlog – distributed Agile and Agile@Scale.
There are a few projects in flight that couple of colleagues are working on that are large Agile programs of work. Large-Scale Agile by James Shore provides an insightful and thoughtful approach.
On a past project we used a similar technique mentioned in James Shore’s post to Using Bounded Contexts to Minimize Dependencies and Using Kanban to Manage Cross-Team Workflow. Though we didn’t use Kanban specifically, the outcome of the approach was similar – when the Team A is ready to work on something new, they took the next item off of the backlog, work on it until it’s done, and then delivered it to Team B that requested it. Where this feature is prioritized in Team A’s backlog is dependent on when Team B needed it.
Not only should Agile or Lean concepts be adopted for projects, but it should also be harnessed at an organizational level to be more competitive.
By focusing more on the bottom line and ignoring the human capital it was one of the reasons What Killed GM:
General Motors managers became very numbers obsessed and bottom-line driven – to the detriment of innovation, creativity and ultimately the product itself.
While GM was obsessing over the bottom-line, it missed the boat on creating automobiles that more people would buy – and love.
And it goes further to say
Lean means more than simply cutting costs or streamlining. Lean, as successfully applied to manufacturing, means doing things “simpler, faster, better, cheaper”. Notice that the last item on the list is cheaper. If you adopt a systems perspective into every business process. You find where the waste is and you drive it out, focusing on doing things faster and with higher quality, cost will naturally be driven out of the system.
In lean IT, the focus is on collaborative teamwork—represented by all parts of the business—to deliberatively and systematically tackle problems. Right now, IT is forced to fight fires every day. The focus of lean IT is to put forth “a set of principles that says you are going to slow down in order to speed up”.
In a recent article, SOA, Agile and Cloud will pave the way to Lean IT, states that:
in fact, cost-cutting itself, the prime mission of every C-level executive these days, essentially becomes a secondary consideration of the lean approach. As organizations adopt lean methodologies and practices, streamlined costs become a natural byproduct of the process.
In the wreckage of a 24 month ERP/ CMS/ Web project delivery at Lonely Planet (so waterfall the program reviews were known as the ‘Nuremberg Trials’), the seeds of an Agile IT organization, coupled with an ITIL focused operations team were adopted to bring Lonely Planet back from the brink of IT. In this case, Agile was adopted not for strategic purposes but for bare necessity and survival. Now under BBC ownership, Agile is a well ingrained habit, with new ventures into book product development using Agile and Scrum – a great example how Scrum can be used for non-IT related business process.
There is a lot of benefit for being an Agile and Lean organization.
The Harvard Business Review has published an article on How Pixar Fosters Collective Creativity in making their movies. The link is only a summary to the full article (which is paid), but it does provide some insights on how Pixar approach their film making.
Building complex software systems is very different to making a blockbuster film, but one thing in common is the people behind it. The way Pixar approach their film making is very similar to Agile practices.
Pixar have cross functional teams – Pixar assembles cross-company teams and find people who’ll work effectively together.
Pixar incrementally build out the movie – Though it is incomplete, Pixar demonstrate the animation work daily to enable the team to communicate important points to the entire crew at once and get candid feedback.
Pixar has self-organising teams – They help the teams to solve issues and the teams are trusted to solve complex problems themselves. People are encourged to help each other produce their best work. Managers are not afraid to hear bad news and they do not micro-manage the team. It is interesting to note that the managers are
okay to walk into a meeting and be surprised.
Pixar is constantly learning and improving they way they work through retrospectives (they called it post-mortems).
Pixar asks post-mortem participants to list the top five things they’d do again and the top five things they wouldn’t do.
This way they can extract the most valuable lessons and constantly inspect and adapt the way they work.
Can you produce a blockbuster software system?
One of the biggest failure to adopt Agile is not having the right mindshift change. This mindshift change can be quite signficant for some. Agile methodologies are a paradigm shift from tranditional “monumental” waterfall methodologies.
Managers and organisational leaders have a key role in helping adopting and transitioning to agile and this starts with the right mindshift change. Esther Derby’s article, The Three Pillars of Executive Support for Agile Adoption outlines what is needed to succeed from managers. What underpins the management support for agile adoption is managers having the right agile mindset.
It can be very difficult for managers to let go of Gantt charts, specific milestones and commitment dates they are accustomed to. No matter that few projects actually meet those targets, managers fear how much worse it would be if the targets and schedule (no matter how unrealistic) did not exist at all.
Ultimately, it will take time to change the mindset and opinion of managers who have dug into their positions over years of working with projects that miss deadlines, deliver low quality, systems that don’t meet customer’s needs, and throw up change control walls.
The 3 points in Ester’s article are not that uncommon.
1. The Power of “No”
How many times do we hear “we have always done it this way”? Manager’s need to demonstrate, subscribe to and commit to the agile practices, values and pinciples and this means not allowing people to fall back into old habits. This includes removing organisational impediments.
It’s predictable that when there’s a new method, process, or policy, people will request exceptions so they can continue to do things the old way.
There will be challenges in adopting any new methodology that you are not experienced with. Adopting agile is no different and will take some time. This is where an experienced agile coach may come in handy to guide the project along to successfully apply agile principles, values and practices.
2. Address Systemic Issues
Ester describes 3 systemic issues.
Three common patterns that I see driving exceptions are technical debt, overstuffing the pipe, and misaligned reward structures.
No methodology can fix these issues. These are management problems, and it takes management to fix them. Without management attention to systemic issues, you will achieve incremental improvements, at best.
Not fixing these systemic issues, Ester rightly points out that this “will sow cynicism in the organization”.
Consequently, agile will be seen as a failure when in fact the cause is nothing to do with the process or methodology used but the lack of management’s ability to address systemic issues.
3. The Ability to Hear Unwelcome News
In the agile community we believe in transparency and visibility. Within HP (and EDS), there is training which educates us to operate ethically and with integrity. To do this teams should be transparent with their management. Likewise, management will need to be transparent with the customer. And this helps build trust with the customer.
Status reports where it goes from green, green, green, green, and then suddenly red should not happen. With focus on working software in small releases, agile methods provide transparency of progress. However, managers will need to have “the ability to hear unwelcome news” should it occur and deal with this effectively.
The four value statments in the Agile Manifesto, shows perferences we should take. Managers have a key role to play when it comes to “Customer collaboration over contract negotiation”. Managers need to set realistic expecations with the customer. Unrealistic expectations lead to shortcuts, continuous fire fighting, accumulation of technical debt, and ultimately delaying the project more.
Management often resort to adding more resources to an already late project thinking more people-power will solve the problem. Ironically as Fred Brooke coined in the book The Mythical Man Month the term Brooke’s Law – “adding manpower to a late software project makes it later”. Instead, Ester encourages managers to —
Take management action. Have the difficult conversations and make the difficult choices to reduce scope or extend the date.
Agile methods don’t provide a silver bullet that guarantees success and requires a lot of management support.
Managment support for agile adoption is not just applying lip service and saying “we will adopt agile”, but demonstration of on-going support. Skills are important, but having the right agile mindset is more important.
A lot of agile is common sense but without the right mindset adoption can be difficult and fraught with danger.