Cynefin Framework in the context of agile vs. waterfall
The Cynefin Framework was developed by Dave Snowden back in 1999, and has since then been used in numerous situations and businesses to describe problems, situations and systems. The Cynefin Framework is a practical application of complexity theory to management science. The framework helps managers determine the prevailing operative context, enabling appropriate choices and decisions (ref Wikipedia).
The never ending religious discussion of agile vs. waterfall can hopefully be a little bit more nuanced seen in the context with the Cynefin Framework
Timeboxing in Scrum
The concept of timeboxing in Scrum is a critical factor for success. Without any timeboxing we quickly end up with inefficient development process, too much overhead and very low velocity. From day one it is therefore important to use the time boxing in Scrum as an effective tool to keep the teams velocity as high as possible.
Scrum is like a game of Backgammon
The first time I learned the rules of backgammon, I was quite surprised by the simplicity of the rules. But as I read some more about backgammon I quickly came across the saying: "Backgammon: A minute to learn a life-time to master", and as I started playing more and more I came across new rules like The Crawford Rule, doubling and a lot of strategy principles! Gradually I realized that the key principles I learned about backgammon is merely a fundament, getting good requires hours and hours of training!
A couple of years later (2005), I came across Scrum for the first time and had some of the same feeling. The principles are few, are theory is very easy to understand! But as I started using scrum, first as a team member, and later as a Scrum master I discovered a never ending series of hard to handle problems and challenges. Today I see my self as an experienced Backgammon player and Scrum Master, but realize that both require both theoretical skills and years of experience!
Here I will present a couple of principles that can help you become a more valued scrum master!
Five key principles to mitigate risk
Releasing new software will always involve some risk of failure whether you do it small incremental releases, or you do it in large cycles with comprehensive testing. There are however some key principles that will help you lower your risk of failure, principles which are easy enough to remember, but which we often don't follow for one reason or another......
Checklists in software development
I guess a big percent of the developers reading my blog have stopped reading already, another big percentage probably still reads, but for the sole purpose to find out what's wrong with this stupid f*** who mentions the words checklists and software development in the same sentence! http://utihagen.com/?p=116
For those how have already stopped reading, there is not much I can do, other than feel sorry for their employers who hire people who wont keep an open mind and try new techniques to make us even better developers!
In most of my professional career I have worked as a consultant, with a constant focus on hours spent vs. value added to my customers. As a rookie you are normally afraid you don't have enough work to fill the day, being a senior or an architect is the opposite, I have too many obligations, too many projects to monitor, too many customers and too little time. And how do we solve this?
I see too many who end up just being the firefighter: always short of time, always on the project where hell has broken loose, always stressed and always cranky! I got tired of being a fire fighter, got tired of being cranky when I came home to my children, got tired of saving the day!
How did I solve my problems? I started using checklists!
Features/Epics vs. user stories in Scrum
As Scrum has grown in popularity, the concept of user stories has made its way from theory and dust covered UML books, to developers every-day vocabulary. In the "old days" we tended to focus on one layer at a time, instead of one user story at a time, we focused on writing large classes supposed to solve all possible scenarios for later re-use instead of simple YAGNI focused classes pin-pointing its purpose and we focused on large-upfront design instead of gradually adapting to the maturity obtained by the customer (and developers) through the project.
We started out with allot of user-stories and even more good intentions, but ended up with phase 2 and 3 and a bunch of long forgotten concepts and diagrams. Today we are not better at planning one year ahead; we have just realized that this is almost impossible. We started focusing on business value which closely relates to user-stories. We started working with user stories weekly and we started estimating and prioritizing user stories in our Product Backlogs.
Daily Stand-Ups in Scrum
I just came across a great summary of the daily stand-ups in scrum, written by Joakim Karlsson. I guess most Scrum teams start out with good intentions and focus in the begging, but as time goes by, we start falling into the old "around the table" reporting habit to the project manager, the Scrum master becomes more and more a project manager, and we gradually drift away from the core principles and ideas behind the daily stand-up!
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2012
Paul Eie
Sponsors
Tag Cloud
Archives
- March 2012 (1)
- February 2012 (2)
- January 2012 (1)
- December 2011 (1)
- November 2011 (1)
- August 2011 (1)
- June 2011 (1)
- May 2011 (2)
- April 2011 (6)
- March 2011 (1)
- February 2011 (1)
- January 2011 (1)
- November 2010 (3)
- October 2010 (1)
- September 2010 (2)
- July 2010 (2)
- June 2010 (2)
- April 2010 (3)
- March 2010 (3)
- February 2010 (3)
- January 2010 (7)
- December 2009 (8)
- October 2009 (1)
- September 2009 (1)
- August 2009 (1)
- July 2009 (1)
- May 2009 (2)
- January 2009 (1)
- February 2008 (1)