One of the reasons I have proposed the concept of CAO (Chief Agile Officer) is for situations such as these where someone at the top level of the organization can arbitrate using the entire organizational as a lens to determine best courses of action. It sounds like you are both on the same organizational level so it would help to appeal to a higher management level in instances where two of the same level cannot come to a satisfactory conclusion.
Once upon a time I coached one of the most amazing agile scrum teams. They were able to deliver things that their management found quite unbelievable so much so that they conveyed a meeting to find answers to why this particular group of people were able to so greatly outperform others in the organization. As an aside I was not originally invited to the meeting but the team lobbies for me to be there as they considered me one of the team and, as a team member, partially responsible for their success.
When You Have A Project Focus Coach: If we take some time to learn and adopt excellent software development practices … More "Are You Crazy?!" – Project vs Product Focus
When trying to get waterfall teams and organizations to move to a more Agile development methodology there are two training strategies – philosophy and practice.
The philosophical approach relies on teaching the history of software development and the philosophy behind Agile – the manifesto and principles. This approach assumes that as long as one is equipped with the proper overriding principles then one will be able to make the correct decisions as challenges occur.
The practice strategy relies heavily on training the ceremonies, especially scrum ceremonies like standups, retrospectives, reviews, etc. This approach assumes that if you do the rights things that overtime the reasons for the practices will become apparent.
Continue reading Philosophy Versus Practice
I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.
While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.
Continue reading Agile = Antifragile Part 2
In Daniel Pink’s bestseller Drive: The Surprising Truth About What Motivates Us, the author persuasively argues that what motivates people in the knowledge economy (of which software development is squarely seated) “is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world. ”
People are no longer motivated by the carrot and stick approach of past Tayloristic, manufacturing, assembly line business. What motivates new workers, and what has been supported by a wide range of scientific studies, can be summarized by the acronym AMP which stands for Autonomy, Mastery and Purpose.
As an Agilist, I am always curious why in one company an Agile implementation succeeds and in another it does not. While there are many reasons for Agile implementations to fail, one thing that many have in common is that they fail to take into account the three factors Pink describes in his book.
Continue reading Drive: The Surprising Truth About What Motivates Us and Why Agile Works
I have recently been reading Jurgen Appelo’s book Management 3.0: Leading Agile Developers, Developing Agile Leaders. For those wondering what management’s role in an Agile organization should be then this is a good read.
In my current consulting gig I am coaching someone to replace me as a scrum master so we spend a great deal of time talking about Agile, Scrum and what it means to be a scrum master.
One of the things I have always used as a metaphor is the concept of Scrum Master (and managers) as gardeners. Though I may have heard it somewhere and forgot it or it may have reached my subconscious somehow, I came up with the metaphor of gardener because my in-laws live with me and are retired. They spend a great deal of time gardening. It is from their work bringing forth trees, flowers and mountains of vegetables that I took my cue.
Continue reading Are You a Scrum Master? Be a Gardener.
“Business people and developers must work together daily throughout the project.”
I was in a backlog grooming meeting this morning when I was given reason to reflect on this, the fourth, Agile principle. The reason was that the team I was working with was struggling/arguing about the proper wording of a story. To a few on the team the absolutely precise wording of the story was of paramount importance. While I am a big fan of precision, the vehemence of the need to be precise was a bad smell. It took me some time to realize where the stridency came from.
Continue reading The Fourth Agile Principle
Of course you would not expect every sprint to have a perfect burndown. You would not expect to complete every story in every sprint (my goal has always been 90% or greater stories complete), but if you are finding yourself with many “overhanging” stories each sprint there are a number of things that you can do to diagnose and fix the issue. In this particular post, I am going to discuss problems with time and hours.
There are three things that can go wrong with hours:
- The number of hours the individual estimates for capacity is too low.
- The number of tasks identified is incorrect (not enough tasks identified).
- The number of hours associated with each task is too low.
Continue reading Not Burning Down? Diagnosing and Fixing the Some of the Problems
I had the wonderful opportunity to have a panel discussion recently regarding Agile. In my warped world, there is no greater pleasure than getting grilled on how Agile can be implemented in the real world. As such conversations are wont to do, a consistent theme emerged. In this particular conversation it was all about Trust.
If someone asked me to pick one word that could be used to describe a low functional Agile team versus a high functioning team, there are two words that come to mind – Discipline and Trust. Of these trust is probably the most important in that it can be hard to acquire, difficult to keep and easy to lose. As a scrum master, my team has to trust that I have their best interests in mind at all times, that the metrics I compile will never be used to punish them. They need to trust each other to be able to commit to a body of work for any particular sprint, etc.
Continue reading Trust and Agile