Tag Archives: agile

Stonecutters, Paycheck Earners, or Cathedral Builders?

All credit for this is due to Mary Poppendieck as this is entirely cribbed from her Agile2007 talk on agile leadership.

A man walks into a quarry and sees three people with pickaxes. He walks up to the first one and asks, “What are you doing?” The first quarry worker irritably replies, “I’m cutting stone, what does it look like? I cut stone today, I cut stone yesterday, and I will cut stone tomorrow!” The man asks the same of the second person who replies, “I’m making a living for my family.” The man turns to the third person and asks him, “so what are you doing here?” The third worker looks up for a moment, looks back at the man with a proud expression and says, “I’m building a Cathedral!”

The moral of the parable is likely clear, but it bears applying to organizational dynamics. Basically, consider that everyone gets annoyed with aspects of their jobs. The question is one of response. Basically, if a person is annoyed with his job, does he:

  • Complain? He is probably a stonecutter.
  • Ignore it? He is probably a paycheque earner.
  • Fix it? He is a cathedral builder.

Cathedral builders are absolutely critical to a healthy organization. They push the organization towards a vision, often propagating the high-level vision throughout all levels of the organization. Unfortunately, these are also people who annoy the stonecutters and paycheque earners, because they won’t participate in the complaints, and they agitate for changes which make it hard to ignore things and just “do the job.” But your success will rely on them… find them, shelter them, and grow them. And whatever you do, don’t “promote” them into positions where they aren’t effective. Empower them, and if you need to add salary and title that’s fine, but let them find their own area of maximal contribution. Guaranteed you, Mr. business owner, aren’t smart enough to see what that is.

Organizations that fail to see this remain mediocre or failing organizations. Organizations that find ways of harnessing their workforce and coaxing people into the next level of engagement, succeed.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Best Agile Practices to Implement Now (Highest Return on Investment)

Everywhere I go, there are three practices that make the biggest difference in overall productivity for teams and organizations. All three practices are part of agile methods such as Scrum and Extreme Programming, but you don’t need to be doing these methods to take advantage of these practices. All of them are relatively inexpensive, and the return on investment for these practices is HUGE!!! Without further ado…

1. A Proper Team Room

This is astonishing: you can expect a 60% boost in team productivity from this single practice! The cost of re-stacking your cubes or office spaces is trivial compared to the benefits. If you are going to do this, do it right! Do the research, hire an agile coach or consultant, and make sure it is done well. One organization I worked with was very excited about their new team room setup. They had a nice open-concept layout with lots of windows etc. But they had also made some big mistakes including that all the developers on a single team would have a low wall separating them from each other. Because of poor layout that would block communication paths, their new setup would actually be worse than their old setup! Some research has shown that you can expect as much as a doubling of productivity (reference). This is one practice you don’t want to let your competitors pick up before you do! Here are some tips on agile team room setup.

Agile Team Room Photo

 

2. Short Iterations

Once you have set up your team room, it is critical for your team to have something to do! The fastest way to get your team doing something is to start using short cycles of work (iterations, sprints) to deliver valuable results such as working software. Many software development projects use iterations that are two weeks long or even a month long. I strongly recommend iterations that are only one week long. Again, the benefits are incredible: your team will move through the stages of team development (forming, storming, norming and performing – reference) much more quickly than with longer iterations or no iterations… thus leading to high productivity much sooner. The value here is in the time gained. This chart demonstrates how this works:

Stages of Team Formation - Waterfall
Stages of Team Formation – Waterfall

 

Stages of Team Formation - Agile
Stages of Team Formation – Agile

 

The short iterations provide a certain type of pressure that forces team and project crisis to happen quickly. However, because iterations deliver working, valuable results, the pressure is not demoralizing, instead it motivates teams to get through the crisis and reach the norming and performing stages of development quickly. Again, to make this work, there are some critical success factors including methods of allowing team commitment, self-organizing and obstacle removal.

3. Test Driven Development

There is a myth that speed and quality are mutually exclusive. This comes from the idea that you need to slow down to make stuff high quality or that you need to sacrifice quality in order to go fast. It is true that initially you might get gains through these approaches. The really amazing thing happens when you try, deliberately and systematically, to do both high speed and high quality work. In software development this is best done through test driven development. In informal polling I’ve done with teams I’ve worked with, test driven development produces a noticeable long-term productivity gain as well as a simultaneous increase in developer and end user satisfaction due to a substantial reduction in defects discovered after the code leaves the developers. I have seen teams doing this that reduce defect rates to 5% (or less!) of what they once were prior to test driven development… while at the same time delivering projects faster than expected. Since substantial expense is squandered on defect management (tools, support teams, user training, lost productivity, etc.) and since staff turnover is also high in IT and high-tech, the results of test driven development on the bottom line are substantial.

The Test Driven Development (TDD) Process
The Test Driven Development (TDD) Process

Benefit of All Three Practices

If a team and an organization adopt these practices, get through the initial cost of learning them, then I would like to suggest that your teams can easily double their productivity if not more. For a team of 5 people working on a 100 day project this amounts to shortening the project to 50 days (save $200,000) or get twice as much work done. Clearly, an organization that adopted these practices and perfected them would save huge amounts of money and would be able to crush any competitors not doing this.

Previously I wrote a more general treatment of the benefits of agile and an article that lists other resources discussing the benefits of agile.

Any discussion of benefits should at least say a few words about how exactly to measure those benefits! However, I’m out of time. How do you measure the benefits of agile?


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

OpenAgile and Small Business Management

For the past three months I have been working with Paul Heidema (our VP of Marketing) to use OpenAgile to run our business.  I thought it might be interesting for folks to see a screen capture of how we have arranged things in CardMeeting to do our planning and tracking. The yellow cards are labels for our Cycles, the white cards are Work Queue items, and the blue cards are Tasks related to the item.  The orange cards represent special information (eg. obstacles or ongoing work) and the green cards represent reflections and learning for each Cycle.

BCI OpenAgile CardMeeting


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Scrum Study Guide is now Available… Really!!!

Scrum Study Guide, “The Best Tool for New ScrumMasters”, is now available at Scrum Study Guide. This guide is designed to be an editable tool for helping ScrumMasters do their jobs effectively. With the Scrum Study Guide you are able to keep track of the rules of Scrum, to keep structured notes on your own job as the ScrumMaster, to maintain a list of online reference material, to assess the progress of your team, and to organize the obstacles you are working on.  It also contains a wealth of reference information for learning along the way.

This is the project I’ve been working on for the last several months that has reduced my output here on Agile Advice.  It represents a huge investment of my time as well as several other people who have assisted me in this including Paul Heidema and Garry Berteig.  Purchasing the Scrum Study Guide, aside from its usefulness as a tool itself, will also give you substantial discounts on other services offered by Berteig Consulting Inc.  Finally, if you like it, you can help to share it by letting us know who should get a discount on their purchase of the Scrum Study Guide.  Enjoy!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Cheaper Talent Hypothesis

Wonderful article by Martin Fowler that discusses the relationship between individual productivity, cost, team size, time to market and value delivered.  Some very interesting conclusions.  This is critical reading if you are a manager!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scott Ambler and ProjectWorld

Nice little article over at ITWorldCanada on “Detailed Development Specs Up Front a ‘Worst Practice’ Says IBM“.  Pretty standard agile/scrum message.  It’s nice to see it being delivered at ProjectWorld.  I wish I could have been there :-)  Anyone reading this at the talk, I would love to hear your comments.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile is NOT a Silver Bullet

The recent growth in the popularity of agile methods such as Scrum is gratifying. However, I am constantly encountering people looking for the Silver Bullet of software development. In the paper written by Brooks, No Silver Bullet[pdf], he describes “accidental” and “essential” complexity. Agile in no way changes his arguments. What agile methods do is to help remove the accidental complexity associated with people and their interactions. This can lead to substantial increases in productivity, but it does not change the hardness of the underlying problem that is being solved by building a particular software system. In fact, doing a good job with agile methods, in particular Scrum, is extremely hard work due to the deep cultural shifts that must occur in order to get the full benefits.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Three Ways of Expanding the Scrum Definition of “Done”

The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this?

Identify Repeating Tasks

Early on, the team will make tasks that include every activity that is done to make software out of the features listed in the Product Backlog.  This will include all sorts of things including “Build login web service”, “Write unit tests”, “Review code”, etc.  Most of these tasks will be thought of in terms of who will be doing them so that throughout the Sprint every person on the team is busy with tasks and there is very little passing of a single task from one person to another.  In other words, one task = one person.

It will quickly become clear that there are a number of similar or identical tasks that show up for most items in the Product Backlog.  If you have to develop a user-visible feature or function in the software, you always need to check code into your version control system, you always need to do some sort of testing on the code, etc.  So you might have tasks in the Sprint Backlog called “Internationalize login panel”, “Internationalize registration panel”, “Internationalize login error panel”, and so on.  Every Product Backlog Item has an “Internationalize ….” task.  These tasks can be abstracted and the “Internationalize” idea becomes part of the Definition of Done (DoD).  It applies for every Product Backlog Item.

You might also have common pairs of tasks where one of the pair is unique to what is being built, and another is attached to it, but common across many pieces of the system.  For example, you might have a task “AnonymousUser class” and an associated “Unit test AnonymousUser class”.  Then you might have another task “LoginErrorHandler class” and an associated task “Unit test LoginErrorHandler class”.  Again, the idea of unit testing then can be identified as part of the DoD.  These apply to every Sprint Backlog Task.

Once these required activities or constraints are added to the DoD, you can then stop identifying them as separate tasks.  Instead, they get represented in some other way in your work environment: a checklist on a whiteboard, columns in a spreadsheet, or checkboxes pre-printed on the cards you use to write Tasks or Product Backlog Items.

Prepare for Release

The software might need many things done to it or around it to prepare for a release.  Often, these things will be put on the Product Backlog  as non-functional business requirements.  For example, it may be important to write online help for the system and this is not currently being done by the team.  The Product Owner identifies that users will need this help and puts it on the Product Backlog.  Yo(1) discovers that These things can eventually be moved into the DoD.  For example, yo puts “Online Help” in the Product Backlog and prioritizes it somewhere near to the point in the Product Backlog when the system will be ready for a release.  The team eventually gets to this item and does it during a Sprint.  At this point, the system is “caught up”, but in order to prepare for the next release, the Product Owner will have to put the same “Online Help” item on the Product Backlog again.  Instead of doing this, it can be added to the DoD.

It is critical that the team agree to add these things to the DoD, and not be forced by someone.  If the team does not feel that it is within their capacity to include something in the DoD, the ScrumMaster should find ways to assist with this: training, etc.  Once something is added to the DoD, it must be completed every Sprint in order to have a successful Sprint.

Release/Deploy to Users

There is nothing like actually getting software into the hands of users to find out what “done” really means!  Similarly to preparing for a release by adding things to the Product Backlog, the team may have a “release sprint” or a “stabilization sprint”.  Everything that is done in one of these special Sprints could and probably should be added to the DoD sooner rather than later!  Again, the team must agree to doing this expansion of the DoD and be supported by the organization so that they have the capacity to meet the DoD every Sprint.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing: The Agile Clinic Service

Berteig Consulting with the help of some partners is now offering a new service called The Agile Clinic. This is not a typical coaching or training session. The entire clinic has a duration of just one day. During this day there are short 30 or 60 minute appointments made by managers, executives, and staff with two experienced agile coaches. These coaches listen to problems presented to them, consult, discover, facilitate, diagnose, and offer solutions. These appointments are designed to be intense and high-impact sessions. Visit www.agileclinic.com to see how this service can add great value and provide fantastic results to your company with a small time cost.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Comprehensive List of Agile Practices

This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices.  Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt).  I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses – if you want it in MS Office format, email me at mishkin@berteigconsulting.com).  I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”.  I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development.  I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve.  Perhaps it could be used in a retrospective setting.  Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients.  If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments.  My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.

Agile Practices Adoption Worksheet (OpenOffice format – 68KB)

 


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Sep 29
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1795.00
Oct 5
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Oct 7
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$0.00
Oct 11
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1795.00
Oct 12
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Oct 17
2022
Details
Team Kanban Practitioner® (TKP)
Online
C$1195.00
Oct 18
2022
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Oct 19
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Oct 20
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Oct 28
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Nov 1
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Nov 1
2022
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Nov 1
2022
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Nov 3
2022
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Nov 8
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Nov 8
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1525.75
Nov 9
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1525.75
Nov 16
2022
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Nov 18
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Nov 18
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Nov 22
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning]
Online
C$1525.75
Nov 23
2022
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Nov 24
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Nov 25
2022
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Dec 7
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Dec 12
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1525.75
Dec 13
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Dec 14
2022
Details
Kanban Systems Improvement® (KMPII)
Online
C$1525.75
Dec 15
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1525.75
Dec 15
2022
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Dec 20
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Dec 20
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jan 10
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jan 11
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1525.75
Jan 17
2023
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Jan 24
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1525.75
Jan 24
2023
Details
Kanban Systems Improvement® (KSI) [Virtual Learning]
Online
C$1525.75
Feb 7
2023
Details