Category Archives: Scrum, XP and Lean

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:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

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:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Flow or Iterations – What Do You Try First?

There was an interesting discussion on the LeanAgileScrum Yahoo Group early in December regarding the difference between flow (lean) and iterations (agile) that caught my eye. I only just now have had the time to write about it.

Continue reading Flow or Iterations – What Do You Try First?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile 2007 Conference Notes – Mary Poppendieck on Leadership

Okay, I’m only here for one day, and the first part of the day was me giving a workshop and then the next part was a presentation on Ruby and Selenium which was interesting (but unfortunately nothing to write home about) and then…

Mary Poppendieck spoke. Here are my notes.

Continue reading Agile 2007 Conference Notes – Mary Poppendieck on Leadership


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Rules

Recently in my ScrumMaster Certification courses, I have been ending the course with a list of the rules of Scrum. This list of rules is based on my understanding and practice and may not be 100% the same as that found in the Scrum books or in other Scrum practitioners’ models. Nevertheless, I just recently checked it against some other online reference material and it seems like a reasonable list of rules. I am interested in any feedback or variations or disagreements…
[Updated: 20070922]

Without further ado, here they are, categorized into Required Rules, Basic Rules and Optional Rules, plus a downloadable PDF version.

Continue reading Scrum Rules


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Better Iteration Structure

In my coaching work, I have often been asked a question about the planning process for iterations, that until just a few days ago, I would actually brush off!!! I didn’t even realize I was doing this, it is only in retrospect that I see this. This question is simple: “how does a team plan for the improvement efforts that come out of the retrospective when they are supposed to be working at maximum velocity when implementing tasks directly related to the items in the work queue?” Or, more simply, “we don’t have time for process improvements.”

Continue reading A Better Iteration Structure


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Nice Interview with Mary Poppendieck

Mary and I worked together for a short time almost two years ago now. When we worked together I was impressed by her honesty, insight and wisdom. Here is a brief on-line interview she has done. It is focused on software development, but many of the ideas she discusses can be easily translated into other types of work.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quality is Not Negotiable

Most of the teams and organizations I coach are working on using agile methods to improve their software development approach. Somewhere along the way, someone has realized that there must be a better way… either better than chaos, or better than bureaucracy. Over the years that I have been practicing agile methods, I have come to believe that quality is not negotiable.

Continue reading Quality is Not Negotiable


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Just-In-Time Value Delivery and Waste Elimination

Lean Manufacturing

If I am manufacturing computers, and I receive a large batch of CPU’s… say… Intel Pentium IIIs, I put them in inventory. There is a recurring montetary cost associated with keeping this inventory. There is, however, also a hidden cost. If I use up half my inventory to build computers, and then I inventory those computers, and I ship half of those computers, I now have 3/4 of my initial chips waiting around, earning me no money at all.

Then, Intel ships the new Pentium 4. What happens now? Well, I basically have to throw out my Pentium 3 stock (either by making low-cost, reduced-margin computers just to get rid of them, or by trying to sell the chips wholesale at cut rates). I also have to either slash prices on my remaining stock of computers, or re-fit them with the new processors. All of this is very expensive, and may eliminate most or all of the profits I was expecting to make on the original purchase. It is a scenario that is rife with waste.

Most manufacturing industry players have figured this out, and moved to a Just-In-Time model of production. Toyota pioneered much of this in the 1970s, and now inventory is seen as a liability, rather than an asset. This waste-free approach is a centrepiece of the Lean manufacturing revolution

Waste and Inventory in Software Development

Unfortunately, there is a parallel in computer software creation that has been rather poorly understood by businesses that need custom software development. Waste can be considered as anything that is unfinished, and/or unused. In software development terms, this can be applied to documents that will never be read or that might be unnecessary, and other such things. It is also true of unfinished software.

Traditional Software Development Example

Let us suppose that we ask someone to develop a piece of software with thirty features. Let us further suppose that this software will take about twelve months to produce. Let’s further suppose that ten of these are business-critical features, and that all of the features’ definitions are highly market-driven.

So a traditional software project starts to develop them. First there is a requirements analysis phase, then a design phase. Throughout there are lots of approval stages, sign-offs, etc. Then some team codes up the software starting somewhere around month five. Coding proceeds for about three months, after which the software goes through a testing process in month nine. In theory, at the end of this testing process (month twelve), we are supposed to receive the software for use, and we should be able to receive the value it was supposed to offer. However, defects are found in testing, requiring some re-work. The software is delayed by a further three months, and we finally receive it. By the time we receive it, our competetors have defined new features, and we have to submit new feature requests, whose results will not be seen for several months.

So for the entire development process, we received no business value, and continued to pay. Fifteen months from first investment until we started to achieve results that could mean revenue from the system. At this point, the software is partially obsolete. This is quite similar to the manufacturing scenario above.

Lean and Agile Software Development

Agile and Lean software development practices change this process by delivering business value a little-bit at a time. In an Agile software project, the business specifies what the most important features are (in our case the ten business-critical ones). The team then begins working in small time-boxes – say, two to four weeks. In each time-box, the team works on a small but well-defined list of features taken from the top of the prioritized feature list that we specified. At the end of the time-box, those features that were worked on are delivered to a degree of quality that each of the delivered features would be suitable for use by the customer. The whole might not be ready, but any features worked-on would be complete and production-ready.

If the team can average about three features per month (about what they pulled off in the above example), then by month four, the team could deliver a piece of software that has all ten business-critical features ready for use. The whole might not be ready, but the customers could determine whether those ten were worth taking the software in its current state, and packaging it up and deploying it. Quite simply, the software may not be “done”, but it’s “done enough”. Then the team can continue to roll-out less valueable features from the prioritized list.

Market and customer needs volatility

This becomes even more important when we consider the competition’s changes. In the traditional example above, after fifteen months, additional features were required. These may have been discovered in month six. Traditionally, these could only be considered in month sixteen. In Agile and Lean software development, however, work on these changes could be started in month seven or sooner. So the business received value early, or “just-in-time”, and they could get high-value changes “just-in-time”.

Quality

Because testing is built-in to the process, the customer is able to validate the product at the end of every time-box, so there are no large batches of re-work. The only time large batches of rework are necessary are when large changes to the basic requirements are requested. And then, Agile does not resist the customer’s desire to change, but recognizes it as an essential part of software delivery, and adapts to the changing consditions. As a result, the Agile and Lean methods are optimized to produce quality product in small increments, so quality doesn’t suffer from customers or markets changing their minds.

Summary

Agile and Lean principles are very powerful, and allow for business value to be delivered sooner to end-customers. This allows for better quality and risk management. It also allows strategic and tactical decision-making by executives to be undertaken when such decisions are most needed – not six months too late.

Firms that embrace Lean and Agile development principles are beginning to see the competetive differentiation that Toyota saw vis-a-vis the rest of the automotive industry throughout the 70’s and 80’s. It is only in the last two decades that, after adopting Lean practices, Toyota’s competitors have begun to close the gap. Agile software shops are beginning to achieve these same competetive gains. Those who don’t adapt to just-in-time value delivery – who don’t eliminate waste in their processes – will feel the results as their competitors take products and services to market far faster, and with more responsiveness to their customers.

“If you’re not on the steam-roller, you’re part of the asphalt.” – Lighthouse Design, circa 1996.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Appropriate Metrics – Continued

Lean Metrics… are Lean


In the book Lean Software Development by Mary and Tom Poppendieck, there are a small number of references to metrics: process cycle time, process cycle efficiency, business models. Lean practices focus very much on diagnostic metrics that are used to help people find and eliminate waste and improve value and quality. The other aspect of metrics is to measure up for purposes of motivation and performance measurement.

Conclusions for Scrum and Agile in General

Don’t prescribe specific metrics!

Agile work is about an empirical process where a team responds to change, learns, and self-regulates. An agile team has the power to choose their own metrics for their own self-inspection. For upper management, the single economic driver that is part of the “Good to Great” process should be sufficient.

See also: Appropriate Metrics and A Metric Leading to Success.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Gathering May 2005 in Boston – Rough Notes

Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn’s presentation on User Stories… but his book (User Stories Applied : For Agile Software Development) is excellent 🙂

The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!’s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum.

Continue reading Scrum Gathering May 2005 in Boston – Rough Notes


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Eliminate Waste

Waste is the result of activities or environmental conditions that prevent a team from reaching its goal. The opposite of waste is something that adds value (more, faster or higher quality) to the desired result.

Continue reading Eliminate Waste


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
May 25
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jun 4
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Jun 8
2019
Details
Certified Agile Leadership® (CAL 1)
Toronto
C$2200.00
Jun 10
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
Jun 11
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
Jun 19
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Jun 20
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1359.15
Jun 29
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 4
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jul 4
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Jul 5
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jul 11
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 16
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Jul 20
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1359.15
Jul 20
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Jul 26
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jul 31
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 31
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Aug 1
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Aug 9
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Aug 13
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Aug 16
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Aug 21
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Aug 30
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1359.15
Sep 7
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Sep 10
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Sep 11
2019
Details
Coach Skills for the Agile Workplace®
Toronto
C$2018.00
Sep 16
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Sep 17
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Sep 19
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Sep 20
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Oct 1
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Oct 4
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1359.15
Oct 12
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Oct 24
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Oct 25
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Oct 28
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Nov 22
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Dec 5
2019
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1599.00
Dec 6
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Dec 10
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Dec 11
2019
Details