More Aspects of Agile Communities of Practice

This is a follow up article to my article about An Agile Community of Practice Starter Kit.  I wanted to share some details on other aspects of CoP’s.

Scope and Nature of a CoP

The scope of an Agile CoP can be of varying sizes and types. The most typical are (most frequent, to less frequent): Organization wide, Localized to a set of teams(Train, Product Group, Nexus, etc), Geographical location, and Organizational department. Organization wide CoP’s tend to be more educational and inspirational in the theme of their activities, while CoP’s localized to a set of teams tend to be very operational in nature. But truth be told, a single CoP can have all 3 of these themes in flight at any one time, only one of those themes in flight, or they could evolve from one to the other, etc.

Educational themed events include webinars and other similar education events, and even providing access and funding for people to attend training or conferences in the community interest. Another educational themed event could be a book club or a study group for achieving industry certifications.

Inspirational themed events includes meetings and other events that are meant to inspire people in the community interest. Some examples:

• An event to inspire attendees to develop a set of skills in the community interest
  “We’re looking for employees who are interested in being Scrum Masters”.
• An event to inspire community members by allowing attendees to be inspired by the success stories from others who have skills in the community interest.
  • “In today’s session, we’ll have 3 Product Owners talk about the very different ways the 3 of them go about Product Backlog Refinement, and all 3 ways are highly successful for their respective teams. We’ll wrap up with how the principles for all 3 are the same, even though the practices are quite different.”
• An event to inspire community members towards personal development in their community interest.
  • “In today’s session, we’re going to talk about a myriad of ways to develop yourself personally as a programmer, as well as some examples to give to your reporting manager so these ways can be included in your quarterly talent development goals. We’d also like to hear some of your ideas on this topic!”

Operational themed events include meetings where inflight product development work or impediments are being discussed. Some examples:

• Scrum of Scrums
• Scrum Master Sync (this and Scrum of Scrums are actually different)
• Nexus Daily Scrum
• Product Owner Sync
• Meta Scrum
• Program Increment Planning (yes, this is actually a very operational Community of Practice if you think about it!)
• Internal Open Source Component Rollout (Internal Open Source Communities are a great way to preserve shared code without having to use component teams)
• Internal Open Source Component Brainstorm Session
• Architecture Advancement Meeting
• Tiger Teams (these are usually short lived Communities)

Work efforts as a result of Community Improvement Backlog Items

One thing to keep in mind about operationally themed events and communities is that all work on the system/product under development still happens on Scrum Teams. Think about production code. If production code is to be written as a result of a Community effort, a Scrum Team must do that as part of their Product Backlog and/or Sprint Backlog. Any other type of work or improvement that doesn’t require production code can be done in a group of motivated like minded community members, or can also be done as part of a team’s Sprint Backlog. As long as it’s not production code, you have total flexibility in how you organize that non production code work.

Regardless of their scope or theme of events, CoP’s should have regularly scheduled retrospectives, regularly scheduled public meetings, and probably also need regularly scheduled private meetings(usually limited to role-players only, but could be other sets of people). As I said in my /CoP starter kit article, a CoP should also have a bunch of Community Working Agreements, a Community Improvement Backlog(CIB), and official communication mechanisms(formal and informal). All of those things still apply of course, regardless of the scope of a Community.

Roles

Community Coordinators(CC)

The coordinators act as the organizers of the CoP, and the main facilitators. One of the principles of a CoP is that you want to build an organization that is more bottom up than top down. Many organizations are coming from strong top down hierarchies. As such, the coordinators must come from the Scrum Dev Teams. You definitely want 2 of them to ensure continuity, and in case they get themselves on the critical path on their Scrum Team or take vacation, etc. At first, they could serve a 3 month term, but once the CoP has been in existence for about a year, you could experiment with a longer term if the community decided to change that agreement. Ideally, at least one of them is more junior, and there is no requirement that the CC be deeply skilled in the community interest. (Remember, there is a different role for skill depth: the SME’s) We’re focused more on people who will inspire community involvement and will responsibly handle community logistics/coordination (aka “social butterflies” and “workhorses”).

When you are bootstrapping the community, give some attention to trying to find a couple of good choices for the initial CC’s, and if they agree to take the role, it is theirs! After the bootstrap, going forward, elections are held halfway into the term of the current position holder so that a nice transition of responsibilities can happen. CC’s should give special consideration to the fact that someone else will likely hold their role soon, and that someone else might completely change direction from the practice or style that you preferred when you were the position holder. To the extent possible, any community formality of any kind should be kept lightweight, easy to transition, and likely to have a long life. This helps ensure smooth continuity rather than volatility in how the community operates. To the extent possible, the CC’s should encourage bottom up self organization of the community. They should also obtain feedback from the community, but if guardrails or executive decisions are needed, the CC’s have the final say over all other positions in this community. Also worth noting that this community likely operates in a wider context (usually a company/org), so all company policies and company leadership roles must be respected or the community faces the prospect of being shut down. The community should feel free to (respectfully!) challenge the status quo of the wider context to increase value delivery, but only respectfully and diplomatically. Bottom up self organization does not mean your community “runs” the company. Role playing note: While not encouraged, only one of the CC’s may hold another position in the same community, and when they play dual roles, they must always clarify which role their input is originating from.

Management Sponsor(MS)

The management sponsor helps get funding and other logistics approved for the community. Ideally, but not absolutely required, the MS is a fairly high up leader in the organization that oversees the community interest. This role is also optional, as a strong community in an organization that empowers communities might not even need a management sponsor.

Artifacts

Community Working Agreements

Your community will likely have some “Community Working Agreements”

Example CWA’s: (We agree that…)

1. The community has 2 “Community coordinators”(CC) who serve 3 month terms.
   [The CC role’s mission is to incubate and inspire self organizing improvement efforts that further the “community interest.” They generally do this via ensuring that logistics flow smoothly and that benefits(improvement value) from “individuals and interactions” are maximized in the community.]
2. CC’s must also be Scrum Dev Team members.
3. It is strongly discouraged to have a CC who resides on more than one Scrum Team. (too much multi-tasking, and residing on two Scrum Dev Teams is weak Scrum practice anyway)
4. Elections for all positions are held half way into the current term to help provide continuity and orderly transition to the new position holders in the community.
5. A maximum of one CC can also hold another position/role in our community.

Hopefully you now have a better picture of some other aspects around CoP’s.

An Introduction to Agile Emergent Architecture – Always Intentional

An Introduction to Agile Emergent Architecture: Always Intentional

Let’s Define Architecture
By definition, architecture is about the major pieces of the system^1, and about satisfying the non functional requirements such as availability, usability, compliance, scalability, security, extensibility , maintainability, and all of the typical “ilities.” It’s important to remember that architecture does not cover anything and everything that can be put into one of the above categories — because they would encompass every last bit of the *entire* system. The architecture should not encompass every last corner of the system. Instead, architecture focuses on the very highest level concerns in each of those categories, and nothing more than that. Further, architecture focuses only on the most basic of building blocks in those categories, and nothing more than that. This leaves as much flexibility as possible for later agility and implementation. So, be sure your architecture is focusing only on the highest of concerns. (The lower concerns might be considered such things as design, code, or implementation)

Big Up Front(BUF) Thinking
Legacy software development approaches put a large emphasis on understanding all the requirements for a system up front. This is also known as BRUF (Big Requirements Up Front). The disproven theory behind this thought is that if one understood all the requirements really well up front, then the most optimum architectures, designs, and software code could be created. As such, BRUF has siblings known as BAUF (Big Architecture Up Front) and BDUF (Big Design Up Front). All of these Big Up Front (BUF) approach theories have been disproven for one overall reason: it takes time to gain this BUF understanding, and by the time you do think you and your team have that understanding, the requirements have changed substantially, which then affects that architecture and design as well. What we have learned over the decades is that the requirements, technologies, users, technical team members, and the market for the product change quicker than we can gain that understanding, and certainly quicker than we can implement an architecture or design. In addition, customers often have trouble describing exactly what they want — they tend to have a much better understanding of what they want only after they see the working software. Further, with BUF thinking, usually the people that did the up front thinking are way different than the people implementing that thinking. So downstream from requirements, when changes to the architecture and design are truly needed, because of all of the previous history, BUF thinking, and totally different people involved, changes are extraordinarily costly *and* complex to retrofit. As such, Big Up Front thinking is a model that has been disproven, so it’s unacceptable, and indeed now.. passe.

No Up Front(NUF) Thinking
However, the other end of the spectrum, NUF (No Up Front Thinking), is also unacceptable. You can’t create a cohesive architecture, that is financially viable, without some good upfront thinking. Without at least some good upfront thinking, the architecture turns out haphazard, almost accidental in nature. Some people have called this unintentional architecture, and the name probably fits.

Signs you MIght be a Victim of NUF
One possible sign of NUF is a system rewrite. A system rewrite is almost always a sign of failure ^2, and the two biggest reasons for that failure are inattention to the user marketplace and inattention to continuous technical excellence via architecture, design, testing and coding practices. Inattention to continuous technical excellence creates what is known as technical debt, which is the other tell tale sign of NUF. Massive technical debt generally presents itself as a highly unacceptable amount of bugs, new functionality that takes way longer than it should, or systems that get jettisoned or re-written. Massive technical debt is pretty much a guaranteed outcome of No Up Front Thinking. As such, since massive technical debt has so many bad outcomes, No Up Front Thinking is also unacceptable.

Big Up Front thinking can lead to No Up Front Thinking
Now, before we move on, let me also address another relevant point. BUF thinking can actually lead to NUF. If a BUF architecture is not kept up to date, is not shepherded, or is extremely inflexible to change, people will avoid thinking about and making architectural changes. This results in NUF and massive technical debt. So, a single system can be a victim of both BUF and NUF. It would be really great if there was a way to find that right balance between BUF and NUF… right?

The Better Way: Agile Emergent Architecture
Enter “Emergent Architecture”, a term suggested by Agile thought leaders. One can think of this as Little Up Front(LUF) Architecture, combined with continuous attention to technical excellence. You could even think of it as “Continuous Architecture” if you so desired. With Emergent Architecture, you do just enough, just in time, at the “last responsible moment.” It’s also important to note that Emergent Architecture is also 100% intentional architecture. Architecture doesn’t just “magically appear”.

The Benefits of Emergent Architecture
By architecting at the last responsible moment, you are minimizing the requirement churn damage that accompanies BUF. By architecting at the last responsible moment, you are taking advantage of the latest and greatest technology knowledge. Finally, by architecting at the last responsible moment, you are very sure that the people collaborating on that architecture are the people that are about to implement that architecture. All of the sudden, the ingredients for success are all in the right place at the right time!

Technical Excellence
Technical Excellence can refer to architecture, design, testing, coding, and probably other practices too. Regardless of whether you do BUF, NUF, or Emergent Architecture, the ability to quickly and cheaply extend or change your software architecture at any given moment is directly proportional to your practices around technical excellence. The higher your technical excellence, the more quickly and cheaply you can change direction (<– indeed, this is the definition of agility). Having said that, in BUF approaches, since people make the mistake of thinking that they can “lock down all the requirements and architecture Up Front” , they rarely put in the technical excellence needed for rapid change. Examples of technical excellence are paired programming, collective code ownership, continuous integration, continuous automated testing, build automation and build pipelines, Test Driven Development, Unit Testing, lightweight code reviews, YAGNI, and many other practices. Agile approaches harness change for the benefit of the customer, so don’t forget Agile Manifesto Principle #9: “Continuous attention to technical excellence and good design enhances agility.”

Architectural Runway and the “Last Responsible Moment”
Now, let’s be careful with the “last responsible moment”. Note the word “responsible” in “last responsible moment.” For different architectural pieces, that last responsible moment will be at different times. Some architectural pieces will require a longer runway, and other pieces can do well on a shorter runway. In summary the more complexity and learning in the requirements, people, and technology, the longer the runway needed. If the complexity factors are low, then less runway is needed. Figure out that needed runway length (length of time before that architectural piece needs to be in place), and work your way back to when that runway needs to begin being built.

Let’s look at some examples.

Architectural Runway for a Deployment Platform
For example, determining the deployment platform(the initial UI, logic, and other tiers) for the Minimum Viable Product for a new product probably needs to happen before the first Sprint of developing that product. Having said that, let’s not regress to BAUF, but let’s do execute some upfront thinking and have that deployment platform pretty well figured out before that first Sprint. Since every Sprint has to include at least some small amount of user/business valuable functionality, it’s going to be hard to create some releasable software functionality *and* create your initial deployment platform all in Sprint 1. It is theoretically possible, but not likely.

Architectural Runway for an Open Source Logging Framework (Complexity is low, should be a fairly quick decision)
Another example of “last responsible moment” might be choosing an open source framework to do logging in your system. If logging is forecasted to be in Sprint 23, there is no reason to choose that framework in Sprint 3. You can probably wait until a few sprints before to begin working on that decision.

Architectural Runway for a 3rd Party Processing Component/Framework (Complexity is high, will be a long duration before a decision can be made)
Let’s assume the same as the above — we plan to begin using this component in Sprint 23, and we are currently in Sprint 3. We need to choose a large 3rd party proprietary component that does a large amount of processing or functionality(think accounting, medical, legal, or aerospace). Since it comes from a 3rd party, there is likely going to be a long runway needed to have that choice in place before functionality can be built on top of it. In this example, it might be perfectly fine to start the architectural discussions about which 3rd party framework to use and purchase in Sprint 3. Remember that you’re going to have to leave time for product evaluation, purchasing, legal, training/learning, and maybe even some technical investigation and technical spikes. It could actually take 20 sprints to execute that particular architectural runway and have the architecture first able to support business functionality.

Architectural Runway for logging standards across multiple teams(Complexity is medium, requires time for buy-in from multiple teams)
Remember that logging framework implemented in Sprint 23? Well, we’re now in Sprint 27, and now that the logging framework has been implemented on a couple of teams, the teams realize a need for standardization of use because the framework is beginning to be used widely across the product. At first people didn’t think this was a “high enough concern” to be considered architecture, but then then they realized that the teams were using widely different “logging levels”, that debug logging often crossed module/system boundaries, and that debugging across those modules was getting difficult. The teams finally realized that there would be some major value in ensuring some light standards were followed across the teams. Three might even be a nice wrapper around the chosen logging framework to make it easier for teams to use in a more consistent way. So, in Sprint 27, they began working on an architecture effort to solve those needs. By Sprint 31, the first teams were using the new wrapper and light standards. One thing to note here is that, back in Sprint 20, when they were originally choosing a logging framework, they could have chose to do all of that standardization up front — but that would have been BUF thinking, and they could not have predicted the ways the framework would be used. It’s very possible that no other team would ever pick it up and use it — as happened with most of their open source frameworks. In other words, they would have been heavily speculating needs rather than having a practical, experienced understanding of the real needs. Now, with the experience of a couple of different teams actually using it, in production, they can make better decisions about how to lightly standardize. In this way, they chose to do Emergent Architecture over BUF thinking.

Architectural Runway for Performance and Scalability(Complexity is highly variable here, depends on the product and the target stakeholders for the release)
Hopefully, if you have a new product, you have a Minimum Viable Product(MVP) release that doesn’t require supporting a zillion users concurrently. However, every product is different, so act accordingly. An MVP will certainly need to perform and scale in a way that meets the needs of the initial users. Get this wrong, and you will pay a very heavy price in terms of customer satisfaction and product adoption. As such, for an initial release, this topic is extremely important. The non functional requirements around performance and scalability will often be ordered high in your backlog, as they are both high value and high risk for an initial release. Having said that, sometimes premature optimization is a source of waste. The runway here will also depend on the tools and environments you need to do proper load testing. Choosing and setting those up can often take serious time, so that would extend the runway needed. So, the runway answer here is probably — “it depends.”

Architectural Runway for Government Regulatory Compliance(Complexity is highly variable here, depends on the weight/complexity of compliance, the agility of the agency, etc.)
The guidance for this piece of the architecture is almost identical to the factors involved in dealing with scalability and performance requirements. They are “must haves” that will often be ordered very high in the product backlog due to their risk and value. Note here that we are mainly discussing compliance needed by the product, not the process. (On a related subject, sometimes software process compliance ends up on your Definition of Done, which may or may not affect the product architecture or product backlog directly.)

The above runway discussions are just some examples to think about. The architectural runway for each of these needed pieces of the architecture will be different. As such, the “last responsible moment” to build that runway will require some serious thought as you refine your product backlog. Further, in order to deal with the unknown unknowns, you’d better put a time buffer into that runway since you can’t possible know the unknowable!

In Summary
Hopefully the above has given you a picture of what Emergent Architecture looks like. With each vital part of the architecture, you will need to consider the runway that gives you the “last responsible moment” and some buffer for the unknowns. Because the requirements will be emerging over time, so too will each of the architectural pieces. The architecture will emerge, or evolve, over time, but with intentional forethought to the necessary runway. Remember, due to the number and churn of moving parts (requirements, people, technology, etc) inherent in almost all software development, the *only* way to keep an optimum architecture over time is to give continuous attention to technical excellence. Finally, in order to avoid the gigantic trappings of BUF and NUF, Emergent Architecture is really the only sane choice.

(If you have several teams on the same product or in the same org who need to keep the Architecture of systems excellent, see:  An Agile Architecture Community of Practice

---

Notes:

^1 The focus of this article is Agile Emergent Architecture, so we give only brief attention to a definition of architecture here. It’s worth noting that many thought leaders have multiple credible definitions of architecture. Further, Martin Fowler and Molly Dishman have mentioned that some think the term “architect” is not even the correct metaphor — that maybe “city planner” is the better metaphor.

^2 It’s worth noting that there are some very rare scenarios where a system re-write might not be a sign of failure. For instance, if the system re-write is an early pivot in a product’s lifecycle, it might make great sense and not be due to the above mentioned causes. Having said that, I’ve never personally seen a re-write that was due to a good reason.

A Response to Mike Cohns Comments on 64% of Software Features Rarely or Never Used

I have a saying.  “Scrum Trainers usually agree on 99% of Scrum, but they spend a lot of time debating the other 1%.”

Let me say this first.  I’m a huge fan of Mike Cohn.  I teach Scrum and Agile classes all over the country at Fortune 50 companies, and it is very rare for a class to go by that I won’t mention at least one of his awesome books on Scrum.  I also recommend him on my list of favorite Agile resources on one of our web sites.  In addition to all of this, I’ve had numerous personal interactions with Mike one on one, and he’s always been extremely nice to me, traded professional practice opinions/advice, and he even offered to let me attend one of his classes at a “trainer courtesy” discount one time.  Great guy!  In summary, I like the guy a lot personally, and I highly respect him professionally.  He’s done a ton for the software and Agile industry, and no one should forget that.

So, with that said, let’s get back to that 1% debate.  🙂

In his recent blog post, Mike reveals some little known details about the oft cited 64% of features that are rarely or never used in software systems.  His information is factual and likely true.  I’m ok with all of that.

What I don’t understand is, why bother broadcasting this?

This is one of the most credible studies available on the subject.  If you think hard about this data for a minute, you’ll realize why it is incredibly difficult to obtain… No company wants to admit that there is a TON of bloat in their software!  But, what percentage of Microsoft Excel/PowerPoint/Word features do you use and benefit from?  What percentage of Rally features do you actually use and benefit from?  Bloat bloat bloat, negative value, negative value, negative value.   In my recent articles on the New New Product Owner, I’ve talked about the need for the New New Product Owner to be a marketplace expert, so that they can maximize the value and profits from software development for their company.

Now, the value equation is way more complicated than “rarely or never used”, but still, I think we all know that there is a TON of negative ROI functionality in any non trivially sized application, and there is a TON of software teams with far too little focus on value and profits.  Anyone who has worked on the front lines of software development knows that.  The oft cited study just helps confirm some of our suspicions.  One of our Agile Metrics consulting services at AgileSoftwareTraining.com is helping to give company leaders even more transparency into how to extract more profits and cost savings out of all of their software development efforts, whether they be internal or external systems.  Give us a call if you’re interested.

What makes that limited study useful as a teaching tool is it gets people to think about value, and think about low value, low ROI features, and realize that value delivery is important, far too important to ignore.

Newer Study confirms the same idea!

Further, Standish again re-iterated this point in 2014, ostensibly from wider data: https://www.standishgroup.com/sample_research_files/Exceeding%20Value_Layout.pdf — “Standish Group research shows that 80% of features and functions have low to no value.”

There are other “studies” cited in our industry that are totally bogus, software leprechauns if you will, and I’m totally against relying on those.  Things like the “Cone of Uncertainty” and the so-called “Weinberg study” on task switching have shown to be totally made up.  However, the Standish Group study is real, with real data, and it is highly credible, even if somewhat limited in its scope.

So, Mike wants us to stop citing the study, or for us to caveat it with “in the weeds” details.  Of course, that will just confuse those new to Scrum and the teaching value would be lost.  And people would focus less on software value and profits.  I don’t think that’s good.  I’m totally open to hearing about a more credible public study, but I’m unaware of one. 

With all due respect to a friendly colleague, and one of the best Scrum trainers on the planet, I think ignoring or caveating the 64% study is bad for the industry.  Let’s just put this in the 1% bucket that we as Scrum trainers will agree to disagree on.  🙂

If you’d like to disagree with my contrarian view, feel free to sound off in the comments below!

The New New Product Owner: The Product Value Maximizer in Scrum.

Preface:  In the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Product Owner role that have far reaching implications. In this article and the series that follows, I attempt to describe “The New New Product Owner” role in Scrum.

In a series of upcoming articles, I will detail the different focus areas that the modern Product Owner needs to concentrate on in order to fulfill their duties on a Scrum team.
The New New Product Owner understands that she will likely need to execute these activities at different times, and that she might need to delegate to others in order to effectively produce software that maximizes ROI for the software development effort.

The first and most important focus area is for the Product Owner to be the “Product Value Maximizer.”  There are lots of way to do this, but 3 key steps are involved:

1. Order the Product Backlog by (estimated) value.
2. Work with the Development team to get small increments of value to market quickly, for feedback.  Release to market = in production, available to end users.
3. Rapidly assess value delivery feedback from the market, and then start over again at step #1.

These three steps will ensure that the New New Product Owner delivers “the right thing.”

Note that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to get features into production quickly, and to assess whether we have “hit the target” with respect to value… or not.  This quick release to production, every few weeks, is a key aspect of Agile software development.

If you haven’t already signed up for our blog, be sure and sign up (upper left hand corner) so you will get the future articles on this topic!

In future articles, I will detail the remaining six focus areas for the New New Product Owner:

• Product Marketplace Expert
• Product Visionary
  
• Product Release Decision Maker
  
• Product Backlog Management Leader
  
• Lead Facilitator of Key Stakeholder Involvement
  
• Effective and Active Scrum Team Collaborator

For a high quality class that focuses exclusively on the Product Owner role(send your business stakeholders too!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.  We teach all over the USA.

User Stories – Focusing on Conversations instead of Writing – Gojko Adzic’s New User Story Book

In my recent article on telling user stories instead of writing user stories, I mentioned that many Scrum Teams focus way too much on documentation and way too little on good collaborations.

More support for this concept comes from the first chapter in Gojko Adzic’s new User Story book, Fifty Quick Ideas to Improve your User Stories.

User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions…. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made…. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations…Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

Gojko has been nice enough to publish the “Tell stories, don’t write them” chapter available completely free here!  It is also important to note, that this chapter is tip #1 in his book, as it really sets the stage for the best use of the User Story practice.

The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth another five minutes of your time to read Gojko’s free chapter, and be sure to share it with your teams and organizations too!

To maximize your Scrum and User Stories practice, bring us into your company to deliver coaching or our User Stories Class.

Focus on Telling User Stories, NOT Writing User Stories

Ebin Poovathany has written a wonderful article on how we should focus more on the verbal conversation aspects of User Stories rather than focusing too much attention on “writing” User Stories. I myself have written an article about this as well (See Trap #’s 1, 8, 10,and 13). It’s great to see that this topic is starting to get more attention in the industry.

As Ebin points out, using so called “User Story Templates” (“As a user, I want..”, “In order to…I want…”, etc) causes people to backslide into older waterfall habits, and creating the same old kinds of documents that we used to create in waterfall, along with the same old problems. He said this is sad, and as a User Story proponent, I agree. It’s a horrible misunderstanding, but it’s rampant in our industry. The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth your five minutes to read Ebin’s article, and be sure to share it with your teams and organizations too!

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

New and Improved User Story Lifeycle Diagram — Free Creative Commons PDF download!

I had a designer friend update my User Story Lifecycle diagram, and she did a fantastic job!  You can download the PDF here:  http://www.scrumcrazy.com/lifecycle

New and Improved Diagram:

The Older Diagram(also still available at the above link):

Other Good User Story Links

• User Stories article on Agile Atlas (New! March 2013 – I co-wrote this one — great article if I do say so myself!)
• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• To see more information on grooming user stories, see:
  • What does Product Backlog Grooming Look Like?
  • Tips for Effective Backlog Grooming
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.
• I wrote a skit for a presentation I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:
  • 

    Script_UserStoryUtopia.pdf

    • Details
    • Download
    • 82 KB
• For good advice on how to split User Stories, see Richard Lawrence’s Story Splitting Flow Chart.
• For a good article on why to split User Stories, see Mark Levison’s Story Splitting, How Small is Enough?

Bradley Bug Chart Referenced in Awesome New Scrum Book

The Bradley Bug Chart was referenced in an awesome new Scrum Book that is now on the market.

Background

I got an email from this guy named Rich one day who wanted to talk by phone and ask me some questions about the Bradley Bug Chart. A great collaboration ensued, and I incorporated some of his suggestions into my chart. A couple of weeks later, he asked me to review Chapter 1 of this book he was writing. I have some of the highest standards around, and I’m not easily impressed, but that first chapter was extraordinary! Through that one chapter, and the conversations with Rich, I realized this guy knew Scrum inside and out. I then reviewed and commented on a few more chapters. I get asked to do unpaid reviews often, but I only spend my time on things that I think are excellent for the Agile community. I’ve spent some time reviewing another book that hasn’t been published yet, and it too, is a great one for the industry in my opinion. More on that one when it gets published.

The Bradley Bug Chart Gets Called Out

A little while later, Rich asked me if he could refer to my Bradley Bug Chart in his book(see page 277), in a section on how to handle bugs in Scrum. I was ecstatic, in part just having my work get recognition, but it was also recognition from someone I highly respected myself. It was great. I also re-wrote some of the praise that I gave Rich on that Chapter 1 review as a quote for his book. Rich also ended up quoting me a few times in other parts of the book, particularly in the chapter on “Continuous Improvement.” I’m not trying to brag here, just sharing the satisfaction of seeing some of my hard work and learning as being objectively recognized in the community.

About the Book

Here is the quote I wrote for his book:

• “Finally a book about Scrum from the Development Team’s point of view. Richard’s description of the best and worst ways to implement Scrum is priceless. The first chapter alone is one of the best descriptions of ‘Scrum done well’ that I’ve ever seen.” — Charles Bradley

I highly recommend his book for anyone working with Scrum and Microsoft Visual Studio/.Net technologies.

Here is the book:

• Professional Scrum Development with Microsoft Visual Studio 2012 , by Richard Hundhausen

Small Caveat: Rich is and was a trainer with Scrum.org, and since our initial collaboration, Rich inspired me to become a trainer for Scrum.org as well. So, while none of this was true at the time of the above events, I wanted to mention that we are now both trainers for Scrum.org. I have no financial interests in his book, whatsoever, and my journey to become a Scrum.org trainer came after my review of his book. Thanks Rich!

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

• The Tao of Scrum – Transparency

• One way to Handle Bugs and Production Support in Scrum

• One way to Handle mid-Sprint Scope Changes in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

I’m Giving a Free Global Webinar this Wednesday on “Acceptance and Story Testing Patterns”

I just wanted to send a quick note to my followers to let you know that I’m giving a free global webinar this Wednesday on “Acceptance and Story Testing Patterns.”

Here is the abstract for the presentation:

Acceptance Testing, also known as Story Testing, is vital to achieve the Agile vision of “working software over comprehensive documentation.” It’s very important that acceptance tests are easily automated, resulting in a phenomenon you may have heard of, called the “Agile Specification.” In this presentation, we’ll discuss eight different patterns of expressing acceptance tests so that they are easy to execute and automate. We’ll talk about popular patterns like Given/When/Then and Specification by Example, as well some other patterns you’ve probably never seen. Attendees will participate in an interactive exercise that will allow them to apply the most frequently used Acceptance Testing patterns.

You can sign up for the free webinar here:

http://tinyurl.com/d4d6ehw