I may have mentioned this before, but I serve as the board president for the local chapter of the Agile Project Leadership Network (APLN) here in Chicago (http://www.aplnchicago.org). Over the years, we have heard a lot of success stories from smaller and medium sized companies, or small pilot projects within a larger framework. We have even heard some stunning success stories of Agile taken to a very large scale. But you would not believe how many large corporations we come across that attempt to bring Agile into their processes because they hear it can improve performance, and then settle for a half-realized implementation and lackluster results. Continue reading “Hitting the Agile Reset Button”
I am frequently asked to give a brief overview of Scrum to people who are unfamiliar with Agile concepts. In the course of giving those lessons, I almost always see a look of shock at the almost cavalier way that we agilists claim that Agile methods will give a better result than traditional methods. I like the look of shock. It shows that they’re paying attention. Continue reading “Agile vs. Waterfall – Improved Performance is NOT Guaranteed”
What do you think about companies that are trying to implement Scrum asking for a Technical ScrumMaster? Can one person perform more than two tasks?
There are dozens of books out there on management and leadership styles. There are dozens of books about Agile methods and the application of Agile principles. There are probably hundreds of books on the psychology of groups. In my opinion, there are not enough books that combine these concepts. The interconnections and application are left as exercises of the reader. Continue reading “Team Building: Five Dysfunctions and Four ‘Ormings”
While vacationing this year, I took my ten-year-old daughter Julia sailing on SERENITY, our Catalina 14.2. Continue reading “Reading the Wind”
As Product Owner for the project, I get to field a lot of interesting questions. I woke up this morning to the following question from one of my teams:
In our current sprint, we have planned 8.5 user story points. But after task breakdown we can see for a couple of user stories, actual story points differ from the estimated story points. What is the correct course of action in this case? Do we need to update product backlog for revised user story points? Then we can say the team is working towards achieving 11.5 user story points! Also, since our [project gate commitment] is nearing, should we reexamine the estimates in the product backlog, and revise them for the remaining user stories?