Category: Lean & Agile

Stories and thoughts about Lean and Agile

Posted on

Wartime Scrum Master

First, some background; this is taken largely from a single book I’ve been reading: Hellcat, The F6F in World War II, by Barrett Tillman, Naval Institute Press 1979.

For many years, there was an aircraft manufacturer on Long Island called the Grumman Aircraft Engineering Corporation. Formed in 1929, this company, during World War II, was instrumental in developing and delivering important military aircraft to both theaters of war, though mostly the Pacific theater. To take but one example, in one month, March of 1945, Grumman delivered 658 aircraft to the United States Navy.

Barrett Tillman, in his book Hellcat referenced above, asserts that the primary reason for the exceptional success of Grumman was superb management. To quote Mr. Tillman from page 8 of the book:

“Equal credit [for this excellent management paradigm] goes to Roy Grumman and Jake Swirbul. They oversaw the efforts of some 20,000 employees working in a 2.5-million square-foot complex, turning out an average of almost one million dollars’ worth of aircraft and parts every day. Even more amazing is the fact that virtually none of the wartime workers had previous experience in building airplanes. A large percentage were women, but Grumman’s turnover rate was less than 3 percent – half the rate for the rest of the industry [my emphasis]. And there was never a strike or work stoppage; the employees saw no reason to unionize.

“In short,” Tillman relates, “Grumman was a happy place to work. Though the payroll expanded to more than ten times the prewar figure, the company still functioned like a small, close-knit family. There were [many] features: [everyone received a Christmas turkey,] daycare centers for children of working mothers, noon softball games, periodic airshows, frequent dances, [imaginative production methods,] even counseling offices …”

With that as background, the following short paragraph, also quoted from the book, will make sense as a sterling example of the idea behind a Scrum Master’s facilitation services to his/her team, so that the team collectively can maintain the utmost focus on the job at hand.

“But the best known, and probably the most appreciated, was Jake Swirbul’s “Green Car Service.” The object was to keep people on the job, relieving them of small distractions. A phone call or a word in the right place would send Jake’s Green Car scurrying off to perform almost any kind of service: fix a flat tire, start a dead battery, make sure the oven was off at home, deliver a message. Anything to keep the employee on the job.”

Cool, eh? That’s a primary goal of the facilitation a Scrum Master provides: keeping people on the team focused and on the job, that part of the job which is adding business value. (Would that we had good ways to visualize the flow of business value! Oh wait, that exact statement is at the top of page xviii of Mik Kersten’s Project to Product; I just began reading this book. It looks good for sure.)

btw here is the NASM page on their F6F-3K. It was an amazing aircraft for its day. (Image credit: defencetalk.com)

Posted on

Remote Story Point Sizing

All you need is a chat window. No really, it’s true. (Though sadly, the reason I’m posting this is because too many companies, even large ones, are astoundingly reluctant to invest in the successful collaboration of their teams.)

Here is a script for sizing a small number of items one at a time using a voice conference call and a chat window; this seems like a small enough technology requirement to assure that almost everyone doing a remote team exercise will have the necessary technology. I’ve been honing the wording on this, as the slightest mistake in wording can lead to someone prematurely showing their size to others, which results in bias.

  • Your facilitator says, “Is anyone NOT clear on the item we are about to size?“
  • If everyone is clear, then the facilitator says, “Ok, without typing the enter key yet, please type your size estimate into the chat window, sending to all; again, do NOT yet type the Enter key.”
  • The facilitator can type into the chat window, “Looking at item <number or description>” – this is an informative interstitial that separates this sizing evolution from a previous one.
  • The facilitator says, “Does anyone have yet to decide on a size?“
  • If not, the facilitator says, “Three two one Vote“, and at that point everyone types their Enter key at the same time, on the spoken word “Vote”.
  • Of course, if everyone is agreed, then your item is sized.
  • Otherwise, one more round of voting can occur as above, after allowing for discussion, remember to get the high size vote and the low size vote in on the discussion to clarify their reasoning to your team. I recommend no more than two voting rounds total to save time.

One can do a Fist of 5 (Fist to 5) in this way also.

  • Facilitator: “I’d like to get a Fist of 5 to ascertain our confidence in meeting the sprint goal and sprint content to which we are about to commit.“
  • Facilitator: “Without typing your Enter key yet, please type your number of fingers into the chat; again, do NOT yet type the Enter key.” Here also, you can describe what each number 0 (or 1) through 5 means as you are accustomed to using this consensus method.
  • Facilitator: “Does anyone have yet to type in a number of fingers?“
  • Facilitator: “Three two one Vote” – as above.

I hope that helps! There are many other ways, but as most readers will already be aware, obtaining an unbiased response from each participant is important.

Theory. If you want to read more, try …

Posted on

Leadership

Reviewing John Kotter’s book Accelerate (XLR8) in preparation for a conversation about a Guiding Coalition. I found this table – about as short as you can get in describing the difference between management and leadership.

ManagementLeadership
– Planning
– Budgeting
– Organizing
– Staffing
– Measuring
– Problem solving
– Doing what we know how to do, exceptionally well
– Constantly producing reliable, dependable results		– Establishing direction
– Aligning people
– Motivating people
– Inspiring people
– Mobilizing people, to achieve astonishing results [including innovation]
– Propelling us into the future


Management vs. Leadership, from Kotter’s Accelerate

As it transpires, this table above was useful. During our conversation we also found a few additional nuggets.

  • Managers often want to be the final authority, to make the decision. They must resist, as encouraged by the principles of trust, empowerment, self-organization … at best, if the team will allow it, they can be part of the team who makes the decision. No more.
  • Product Owners make decisions like managers often want to make. If that kind of decision is needed, go get the Product Owner.
  • All this desire to be managed is amplified by the next fire drill. Two things about fire drills:
    1. Fire drills encourage management-style thinking in people not accustomed yet to being leader. Specifically they may try to abandon process to get it done quicker. As my mentor Murray Cantor would say, do not abandon process. If it’s not going fast enough, improve/modify it for speed, but do not abandon it.
    2. Managers get tired of the phrase “everything is an experiment”, especially during the next fire drill. And yet experimentation is what is needed to become more Agile. The thing is, sure, it is an experiment, but it often comes without the option to fall back, to fail backward. Therefore, plan to fail forward. Experiment continuously, but plan to fail forward. No failing backward, only forward.
Posted on

Working Agreements

I was about to write a post on working agreements with an emphasis on their use in Agile Teams. There was no need – the wheel has already been invented! and is right there on the amazing internet. I encourage you to read these two internet posts in order; they’re both short. The second one has a video with dogs in it – that can’t be bad.

Posted on

A wee bit of predictability math

Agile teams who start their Agile journey in Scrum quickly learn something called story pointing, and how to use it to enhance their predictability. (Hopefully they also learn to avoid trying to leverage story pointing to understand productivity, but that’s a separate story.) Anyway, there are many internet references to story pointing. Pointing is a clever way to avoid the need to make all the stories in our backlog roughly the same size prior to implementation.

When the team is also developing on a static cadence, say a “sprint” length of two weeks, then we can call out a set of stories, put them “in” our sprint backlog to be done in this sprint, add together their story points, and call that our forecast, say 40 points. It used to be called commitment and I still think that’s a good name: we commit to the Business that we’ll do everything we can to make our forecast. We can do that because we’ve established historical perspective that tells us we are consistently able to complete that many story points in every sprint. Jira (among many tools) shows us this in the Velocity Chart report.

Velocity, then, is about a forecast over a static time period. However Kanban teams are among those who don’t “sprint”; they don’t develop on cadence. They do demonstration and review on demand, and to establish predictable behavior they consider flow instead of velocity. They have more work to do on their stories: instead of pointing them, a Kanban team needs to split their stories until all the stories they develop and deliver are about the same size. When that is true and if we are on a cadence, we could switch our units of velocity from story points per sprint to stories per sprint and it wouldn’t matter much. When we are not on a cadence as on a Kanban team, we think about flow instead, or the average time to complete a story once it is selected for development; this is called Cycle time. (Separately we can have a discussion about the related measure, Lead time.) Note that Cycle time and Velocity are inversely proportional to each other if both are being measured with the same units (either stories, or story points). Example using stories:

Let Velocity be the average stories per sprint
Let Flow be average days to complete a story
then Velocity = L / Flow
where L = sprint length in days

If we are using story points rather than stories, and not trying to get all our stories to be about the same size, Jira only helps us if we are on cadence, ie sprinting. Jira does not measure cycle time for story points, only for stories, so a story point-based cycle time must be calculated manually. That being the case, we discourage story pointing unless our squad is sprinting. Instead we encourage splitting our stories until all the stories we select for development are of similar size.

Cadence, such as the sprints in Scrum, is very useful. Teams typically thrive on the rhythm and story pointing is not difficult (at least, not once you “get it” – yet another separate story!). Kanban teams have more flexibility but as is so often the case, it’s a trade off: more discipline in story splitting is needed to be successful.

Posted on

The Rudiments of Retrospective

I want you and your team to have good retrospectives. Retros are the most important mechanism for continuous improvement. There are so many articles out there with good advice. But I’d like my own anyway and discuss a few concepts.

Method variance (part of facilitation)

As I write this in late March 2020, most of us are WFH – working from home, due to the COVID-19 “Coronavirus”. Eliminating the ability to collaborate face-to-face makes varying the conduct method of your retrospective even more important. This is because the variance subtly motivates different perspectives, and that is an important way we discover new things to try (experiment) to improve. For example, suppose you want to hear from every team member. You can call on everyone in turn as the Scrum Master. You can ask each to choose their successor, you can intentionally randomize. You can ask “who would like to go next?” Each has advantages. Choose a different method for doing business as often as you can. Here is one ‘net resource discussing this idea; here’s another.

Framework variance

Most retrospectives have a framework for engaging in discussion resulting in specific elements of continuous improvement. Vary this too; no matter how inventive it is it gets old with overuse. Start/ Stop/ Continue is great, but there are so many others, some with interesting names like Sailboat, and again each results in different perspectives. Here is a list of 10 different frameworks including Lean Coffee.

Agenda

The agenda for a retrospective is more than just executing the framework. It’s also a look back and of course a look forward. Here is a sample agenda with a beginning, the “meat”, and outcomes:

  • Introduction (try the Retrospective Prime Directive)
  • Celebrations
  • What were the three (no more than 3) behaviors we decided to change last time? How did that go?
  • What were the three (again, no more than 3) retrospective backlog items, actions, we decided to work on last time? How did they go?
  • Framework choice (see above)
  • Framework-based, facilitated retrospective free discussion
  • What are the < 3 behaviors we will change for next time?
  • What are the < backlog items of continuous improvement we will work on and complete for next time?
  • Other remarks / Conclusion

Inputs

  • An invitation to meet, with agenda
  • Recent behavior changes – let’s call them decisions – we’ve been experimenting with (an example: we decided to do three backlog refinement sessions last sprint instead of two, how did this go?)
  • Recent backlog items – actions – associated with retrospectives (an example: we added a Jira issue to build a Slack bot to do (whatever) is this done and how is it working out?)
  • Framework choice (or, this might be revealed during the retro session itself)

Guidelines

  • Ensure that your retrospectives occur sufficiently often. Less than monthly is almost certainly unacceptable.
  • Ensure that the feeling of the session is not that of a report or reports. It is a collaborative discovery session.
  • Allow for anonymous input. If you were all in a room together, the next sticky note you place on the wall in conjunction with your framework-based discussion is at least somewhat anonymous. When we discuss it, the person who wrote it may or may not speak up, and if they do they may or may not own up to having written it. Try to encourage this kind of anonymity, as it frees up discussion and makes more innovation possible.
  • Take inputs and group them to improve effectiveness. It’s ok for multiple people to say the same thing. Group them after collecting them, to facilitate discussion. The face-to-face method is to grab stickies and group them together. Do what you can if you’re remote to make this happen.
  • Take your team’s inputs and prioritize them, at least most of the time – perhaps in the interest of varying method you don’t always do so, but most of the time you should. The Lean Coffee method works fine, most votes is highest priority. Discuss the topics in priority order.
  • Have fun! Celebrate!

Outputs

  • Those behavioral things we’re going to change and experiment with, that is our decisions, and
  • those actions we’re going to work on, and which therefore will appear in our backlog, both of these first two bullets in the name of continuous improvement
  • the date/time of the next retrospective
  • Don’t forget to celebrate! You need to work that in somewhere.
Posted on

The Rudiments of Asset Management

There are two topics herein; the first is on reusability with Microsoft™ – powerpint in particular, and the second on initiating a reusable asset program.

In one of my recent “previous lives”, there was a pressing need to produce reusable intellectual capital (IC) to permit our consulting and coaching practice to grow. The shame of it was, we just couldn’t do it. Because of time constraints (gotta be productive!! gotta be chargeable!!) we were unable to effectively codify what we learned so that subsequent practitioners could build on that learning. We also tended to put everything into PowerPoint™ [1]. (I call it powerpint, I hope that doesn’t get me in trouble with Microsoft trademark enforcement!) 

As it transpires, it appears to be very difficult to develop effective reuse patterns for powerpint; we didn’t find a way. The elements of reuse are single slides or small groups of slides, and the elements of configuration management are larger and essentially indivisible groups of slides called decks. This impedance mismatch makes a simple reuse task boringly and tediously difficult. (And it’s much more difficult when the only “asset repository” your organization makes available is email – s-m-h.) I’ve heard there is a composition manager available to pull the current versions of single and small collections of slides into “the next deck” but I’ve never been in an organization that uses this composition manager, if it even exists. I suppose it would be possible to code it up in Visual Basic™, but I’ve not seen that done. 

A conclusion is, yes, graphics are important, but use them effectively and if you are building lots of pictures, consider changing your paradigm from glossy powerpint to meaningful semantics with a genuine model-building application whose diagrams are views into the underlying, all-important semantic model. When I was at IBM, our original go-to for this was Rational Rose; later it was Rational Software Architect. I’ve not found a free UML modeling tool that will do this job with any clarity but all the ones you pay for probably will do it. Unfortunately, this results in the need for a considerable investment in training time and tools. I’ll consider this aspect more carefully another time. Meanwhile …

Developing Reusable IC while Engaged

The best way to develop reusable capital is for its immediate use in the context of one’s current consulting/coaching engagement. One is on the ground, executing, and realizes the need for something, for the benefit of the client. Sometimes it’s a new way of doing business. Sometimes it is an artifact or collection thereof that can be used to facilitate some processes. Usually, it’s both, actually. You build what you need, you try it out and experiment with the client or customer, you refine it based on that experience, but not too much to avoid gold-plating[2], and then you submit it to the asset repository. And there it sits, waiting for the next need.

The key to its eventual excellence is its reuse, and the first criterion for that is someone who needs it actually finds it in the repository – we’ll get to that in a minute. Effective reuse does not always look like, “Oh, here! This is perfect! This is exactly what I need!” This is often called pulling the asset off the shelf. It’s rare, but it’s nice when it happens because you’ve found something that will save you work. More often though, effective reuse looks like this: “This might work. I’ll make some refinements to suit my client’s situation and then give it a try.” Once it’s been refined and used, it is reviewed and possibly refined again – but once again not too much to avoid gold-plating2 – and placed back into the asset repository as an update or new version for the next consultant/coach to use.

Note that now, this asset is useful in two different engagement contexts. When a third context arises, it is likely to be better fit-for-purpose and require less work to get it to the point where it is usable in that new context. (It is important to ensure that you don’t break it for purposes of previous contexts to which it has already been applied.) In the fourth context, it’ll be even better. It might never be reusable just by pulling it off the shelf and starting it up. Some small amount of configuration or customization might be required every single time it is used. But it is better every time due to the continuous improvement applied to it, and due to the time and especially thought savings associated with its reuse.

Finding the Asset

I learned the above Build-while-Executing pattern for building and maintaining quality reusable engagement assets while I was at IBM. Most of what I learned came from the gentleman who led the small staff of, well, I’ll call them librarians, who made the asset repository sing; his name is Darrel Rader. Believe me, I consider the role name librarian a compliment. If I recall correctly, our consulting staff was about 500 worldwide and his staff numbered maybe 5. Maintaining the collection of reusable assets in a suitable repository – indeed a repository designed and developed by a team at IBM Rational led by another mentor Grant Larsen, for expressly this purpose – was hard work. This investment paid off extremely well. Hundreds of engagement assets were pioneered and then refined in engagement after engagement, and it served to save consultants lots of time and improved engagement quality significantly as time passed. I can only hope that the repository still exists and is maintained within IBM. I’m afraid I don’t know.

Darrel spent an impressive amount of time on Search and Find. It turns out, for Darrel and his crew, the assets were the easy part: the consultants built them on their own and were happy to do so! On submission his crew would review an asset, possibly suggest minor improvements, and then categorize, package and tag the asset within the tool, called Rational Asset Manager (RAM). This was really important, because if it was poorly packaged it would be hard to reuse, and if it was poorly tagged, no one would ever find it.

Packaging

Packaging proved to be extremely important in order to avoid duplication of artifacts. It is worth pausing here to provide a few definitions:

Artifact: a document, for example a powerpint deck, a word document, a spreadsheet, a text file, a model file. A single thing. If a group of files belonged together tightly, then it might be a zip file containing those in that group. But an artifact is a single thing. An artifact can be a reference, that is perhaps a URL or some other reference which points to the physical file located in some other repository like Jive™ or Sharepoint™ or git™. And finally, an artifact should be (or become soon) a formal member of one or more assets. Artifacts can be tagged.

Asset: a governed and audited collection of related artifacts with a declared purpose. We endow the asset with a lifecycle to promote an asset-based form of governance, that is we make decisions on how the asset can/should be used by reviewing the quality of the asset when or after work is done on the asset (not just on whether the work is “done”). We enable this by endowing the asset with a lifecycle (state machine) – probably derived from its type, and a state within that lifecycle. As mentioned above, an artifact might be found in more than one asset; as such, it should be equally usable when sought by practitioners looking to use any asset which references that artifact. Assets must be tagged and categorized; one must be able to find them when they are a possible contributor to the solution to a consulting/coaching issue.

The flexibility implied by the above packaging implies that there is work to maintain the packaging. A category hierarchy must exist, but much more importantly, a tagging taxonomy must exist. We found as this capability was being developed at IBM that we quickly lost control of tags. We solved this problem by enforcing that tags be part of a managed tag taxonomy. If you needed a tag that wasn’t in the taxonomy, you went to Darrel’s team, and either they would find you the tag you needed, or they would invent one with your concurrence and place it into the taxonomy, and finally tag your asset with that tag.

Searching and Finding

The taxonomy was the single most important element of the librarians’ efforts making the reusable asset repository useful in the long term. Put succinctly, if you were looking for something, you consulted the taxonomy, chose your search terms, did your search, and behold … assets worthy of your consideration for use/reuse.

Discipline and Evangelism

A most important role of the librarians was evangelism. Encouraging practitioners to build and submit, or find and refine, assets in conjunction with their work never stopped. This would not have worked had the practitioners (coaches and consultants) lacked permission and the resources to build, refine, and share ownership over our reusable assets. For example, if one is continuously “full time” on engagements, asset development rarely occurs. It was also common for the librarians to review a proposed submission and suggest combining it with a previous submission or two to make a refined asset rather than a new asset. It remained difficult to find what you were searching for even with all the effort on tagging. But it was possible and worth the effort.

Summary

The above constitutes the beginnings of a genuine intellectual capital development and leveraging strategy, backed up by an ongoing investment in growing capability, both in tools (repository) and labor (librarians and consultants). The result was a robust reusable asset management program that yielded higher quality consulting and continuous improvement. It also made IBM a joy to work at, because your work was acknowledged and supported. Indeed it was specifically measured by reuse! and rewards acknowledging contributions were possible based on the measurements. Indeed my friends, those were the days. 

[1] with apologies to Microsoft™ because PowerPoint isn’t really a bad product, just a horribly misused one. I do have a friend who says “we are all subject to the vast mediocrity of Microsoft”, but that isn’t quite true, although it does often require organizational buy-in. If we have that, we can rise above it with some effort, and it’s often quite valuable to do so.

[2] Gold-plating, see https://densmore.lindenbaum.us/dysfunction/rock-engineering/

Posted on

Systems, Complexity, Crashes, Oh My

This blog entry is written together with my old IBM buddy Mike Mott, Distinguished Engineer Retired[1]

As my colleagues and friends are aware, I am fond of discovering unbridled and poorly managed complexities that result in bad stuff. I don’t look for such issues that have killed people, though it has happened. But pretty much everything else is fair game, including the YF-22 accident where the test pilot left the prototype airplane via the ejection seat because he suddenly was utterly unable to control the airplane. As it transpires, there was a section of computer code tasked with translating pilot commands into control surface actions where there were eight discrete modes, and the pilot had unwittingly flown into the one of those eight that had never been tested until now. There was a sign error. Up was down, down was up. Close to the ground, there was no time to figure it out. Scratch one really expensive fighter jet. 

A recent, and very public, complexity issue presents itself as a target rich case study for how to avoid doing business with software, and that is the results reporting from the Iowa Caucuses. There are much better approaches to the management of high-tech programs.  There is a huge difference between hacking out an app for a smart phone and building a system to support a caucus.  The app is used in support of a process of vote counting, reporting and summary.  All of the people involved in this process must be properly trained to perform their roles.  The app must be realized in hardware, which requires loading and testing of the app in the production environment.  The networks and servers that realize the results must provide enough capacity to perform the computer tasks within the timelines. Use Case modeling of the end to end system operation is an excellent way to flesh out the preparation work for the caucus and the performance of the precincts on caucus night.  

Surveying websites such as sysml.org from time to time, the trend is good; modern system management technologies are evolving well.  However, reviewing pmi.org, it is still stuck in the past with the same old work breakdown structuring and risk management approaches that we know lead to long feedback loops, poor quality and performance issues.  There is a gap between the technologies available for the system itself, for system development, and for the approach used by program managers to pull it off.

Now, as my buddy Mike writes …

Looking at Iowa from afar, it seems obvious there was a total failure to plan the scenarios, the intended results, the usage models … or maybe anything at all, as though it was just going to work.   I would bet the house, farm, and alley cat that no clear-cut statement of objectives were ever written or socialized. They needed measurable outcomes to shoot for, something like “we shall have the conference results complete within 2 hours of when the doors close to start the caucuses”.  Another bet: not a single Use Case (or Epic, or group of scenarios, or whatever you want to call it) will be found in their statements of need that lays out the entire process of taking votes to result.  And stunningly, it appears that no thought whatever was given to the hardware realization. They left it at “hey, we have an app”. According to Chad Wolf, Acting Secretary of DHS, during an interview Tuesday on Fox and Friends, there was no viable test plan, and it wasn’t for lack of resources, the DNC actually declined an offer to test the system by DHS’s Cybersecurity and Infrastructure Security Agency. It also appears that the folks involved even now don’t understand what happened. All these issues are being spoken of by the DNC as a simple app failure. Indeed, that’s a piece of it, but astute observers know that the larger failure was one of project management and/or product development management.  Success on a crucial, scaled system must consider the people, process, tools, and technology.  But no … they believed an app purchased from Mrs. Clinton’s former campaign manager would ensure the caucus ran well.

Alas, this seems very typical of how government spends our money.  Even after so many lessons, in the form of failed systems, have been rolled out for the world to see. The government lays out huge projects that fail time after time, with billions wasted. Is there no self-reflection or retrospective at all? There doesn’t seem to be. Would it not make some sense to seek assistance from those who have actually delivered on big efforts?  On this point, it is notable that Vivek Kundra, young Ph.D. IT wunderkind, President Obama’s information czar and the first CIO for the federal government, invited major players in the industry to come and explain to him how the government could improve their IT performance. I developed material on the topic for my colleague Dave McQueeney, still at IBM, who pitched the slides to Kundra.  To his credit, Kundra eventually published a 25-point plan to improve the federal government’s IT performance. He leaned more heavily on Agile principles and Agile methodologies than on the architecture quality-driven Model Driven Systems Development (MDSD[2]) process framework we developed at IBM Rational to manage such high-complexity programs. Alas, I understand that IBM just didn’t quite connect with Dr. Kundra.  Today, he is out of government, and the initiatives he started spent around $1 billion – they never die! – but are effectively complete.  

As a number of outlets reported, the testing of the app was limited (ref Slate[3]).  Indeed.  Pulling on this notion of a system – the app was part of the larger process of the caucus.  The caucus leadership had a process to follow.  Was it documented? Was its use rehearsed?  Obviously not.  According to Slate, “The problem with the caucuses is that we don’t run them except in a major national election, so there’s no way to ramp up to it. Imagine going to war with only war games under your belt, without facing an actual battle.”   Although they knew this, the Iowa DNC failed to properly train their people in the use of a new app; ensure that the new app was installed and ready to go; or verify that the system hardware was scaled properly to support the load.  

Ok, Jim here. To summarize, it seems certain that eventually … eventually … the ideas of incremental development yielding short feedback loops, ongoing risk mitigation, more objective and measurable criteria, end-to-end testing of the technology with the processes, and explicit management of system architectures as represented in multiple stakeholder viewpoints will get through to the Project Management field.  It appears to Mike and I that the expected path for that will be via Agile. Indeed, as it evolves, it is adopting many of the tenets of of MDSD. 

[1]  https://www.linkedin.com/in/michael-mott-3590997/

[2]  https://www.academia.edu/9790859/Model-driven_systems_development

[3]  https://slate.com/technology/2020/02/iowa-caucus-app-fail-shadow.html

Posted on

to Kanban from Scrum

I recently transitioned a team from Scrum to Kanban. Here are some of the things I learned. Those of you experienced in Kanban – I’m really not – will probably find this boring. Many of these items are bread-and-butter for Kanban.

  • Kanban has less formality but requires the same degree of rigor as Scrum or even more. This implies a greater requirement in Kanban for discipline, enough so that teams can do it, but are unlikely to do it well, without focused help from a good coach, unless the Kanban Master is quite well-trained. That is, Kanban Master(s) needs to be higher quality with respect to Agile and Kanban techniques than are most Scrum Masters with Scrum techniques, for the team to be successful.
  • Kanban is Lean. Start with what you have, keep learning, and feel very free to change and expand your board. More columns, maybe more rows, and make it truly live and visually representative of your current work, state and needs. Be incremental. Experiment, try stuff, continuously improve. Focus on pull in lieu of push. (A good and easy example of pull is inserting a new column in a Kanban board between In Progress and Testing called Ready to Test.) Oh, and read Kanban by David J. Anderson. Don’t argue, just go read it. I found it a challenge to find the board online that I wanted to cite as a good example. Here’s one that is not bad, take awhile to just study it and think about what they must be doing and how it visualizes things for the team.
  • Policies. Each column-to-column move made by a work item is a state transition; endow each state transition with a policy. In Scrum, from In Progress or Doing or Testing or whatever to the Donecolumn (state) has a policy associated with it called Definition of Done. Optionally, from Backlog to In Progress has a policy associated with it called Definition of Ready. Each policy specifies the conditions that must be true to allow the state transition, as well as the actions to be taken when the transition is performed. In Kanban, all possible state transitions should be endowed with such a policy. They don’t need to be lengthy, but they definitely should be visible and easily found so that they are quickly referred to during work and updated during retrospectives with new knowledge gained.
  • WIP. Going from Scrum to Kanban made the transition from (work in progress naturally limited by 2 week sprints) to (WIP limited poorly and without a strategy) painfully easy to see. Shoring up the WIP limits to enable good flow and predictability became priority almost immediately. Fortunately it’s not difficult as long as the principles are understood. The rule of half got us in the ballpark: Team: “is this about right?” Coach: “try half that”.
  • Reviews. In Scrum there is a sprint review every two weeks. Everything forecasted for a sprint is reviewed or thrown back into the backlog if not done. In Kanban there is no such formalism, but every work item should still result in a product improvement that is executable, demonstrable, and demonstrated to a product owner or stakeholder(s) and approved. Visibility is key, so put the appropriate state transition into your Kanban so that you can know that all your work items pass this “it’s done, and it’s approved” policy test. In addition, don’t underestimate the value of cadence; maybe you should keep reviews of your working stuff on a regular cadence. Kanban doesn’t care; if it adds value, do it. Does that make it Scrumban instead of Kanban? Not sure, and not sure it matters, but rhythm is often useful to a team.
  • Retros. In Scrum there is a retrospective every two weeks. One must account for this functionally. In Kanban, once again, the retro does not have to occur on cadence, but experience shows it has to occur with similar frequency in order for your team to qualify as a team seriously engaged in continuous improvement. My suggestion: stick with what you did in Scrum, if you can. Set up a convenient time, and do your retrospective every two weeks on cadence. If this is the only thing you do on cadence, I believe it’s the best thing to do on cadence. Retros are the most important event, right? Rhythm is useful to many teams (see previous bullet), and it is a reason Scrum is so easy to like.
  • Kanban doesn’t have a Product Owner. I recommend a Product Owner anyway. Bring someone in from the Business who will do the things a Product Owner does. Make that person a full-time member of your team.
  • Kanban doesn’t have a Scrum Master. I don’t recommend one, but I almost do. You need a level of effort of approximately a one full-time person to engage the team in continuous process improvement, remove impediments, and facilitate ceremonies/events of importance. In fact, maybe the LOE is higher, because Scrum’s processes are straightforward whereas Kanban is nominally very flexible and dynamic. My suggestion then (falling just short of a recommendation), is to avoid underestimating the value of a single, dedicated person who acts for your Kanban process as your Scrum Master would if you were using Scrum. Call him/her your Kanban Master perhaps, if you as a team decide to leverage this idea. Be sure that person reads Kanban.
  • Story pointing or story sizing. Predictability is a major element of growing maturity as a team. In Scrum, we often perform Story Pointing as a part of backlog refinement, to understand the relative size of each work item (many of which are user stories, hence the name). However, in Kanban, one doesn’t measure velocity because there are no sprints. Instead one measures lead time and cycle time. For this to work well, each work item needs to be “about the same size” as its brethren. Story sizing keeps this from being a need, but story sizing only works if you’re on a static cadence like two weeks. If you have some 1s, 2s and 3s floating around, you’ll probably be ok with the assumption that all stories are close enough to the same size to ignore their differences. If you have some 2s, some 3s, but a 13 or three as well, then the assumptions of similar size required by the lead time and cycle time measurements don’t work as well, and those measures won’t help you nearly as much to understand your predictability. Therefore, a significant element of improving maturity with Kanban is to solve this problem by splitting those 13 point user story into stories that are 1, 2 or 3 or so in size, that is, all of similar size. And we don’t do this by explicitly sizing the stories, we just split them until the collection of stories all are “about the right size”.
  • Story Understanding. On the other hand, part of backlog refinement is ensuring that the whole team understands the needs represented in the backlog. My experience is that this happens very naturally when stories are routinely sized. If the team stops sizing stories, they often forego exactly what it takes for them to have an adequate understanding of the stories. Quality suffers. Thus, even if the team is not sizing stories any longer, they still need to understand them as well as when the stories were being sized. The team must figure out how to maintain that sufficient level of understanding of the backlog.

Hope that helps! Keep learning and improving.

Posted on

Scrum Cookbook

Scrum is easy! No really, it is. Doing Scrum well is quite difficult, but doing anything well usually takes thought and practice. We can start right in though. First, read the Scrum Guide at scrumguides.org . Second … follow my cookbook! Now laugh, because of course it is not quite that easy (and you can tell that because this is not a short post!), but once you have received training this cookbook may be a resource you and your Agile Coach can use to jumpstart your transformation to execution using an Agile paradigm.

Scrum can be used to quickly lead a team to the Agile Minimum Viable Product (to paraphrase Mike Cottmeyer): that MVP is (1) a genuine, collaborative team, (2) a single-source product backlog, and (3) frequently executing stuff. If you have these three items and you have a continuous improvement mindset, you’re genuinely getting close to Agile.

Ok, so have you read the Scrum Guide? No? Go do that, I’ll wait. Now let’s get started. Please let me know if you have any comments or questions.

Preface: Recently Scrum and Agile have been moving away from the use of the word ceremony, choosing instead to call them events. It is important that we stay away from the word meeting, because that means a gathering that is not in scope for core work, whereas a ceremony or event is intended to be exactly that. In this paper I’m going to stay with ceremony because it seems to stand out a bit more, but the Scrum Guide calls them Events.

Communications Guidelines

The following are suggestions for enhancing communications and collaboration, especially intra-team, particularly when there is involvement in multiple geographies. A multiple geographies situation is highly discouraged, but we are finding that they’re unavoidable. What I mean by this is most clients of Agile Coaches don’t respond well to the suggestion of colocation unless they already have it; they’ve invested (sunk) too much into distribution and emotionally they can’t just let go. (The admonition to ignore sunk costs usually does not help as much as you would like.) If the Coach insists, they usually throw out the Coach and s/he has no opportunity to help. I conclude that moving to colocation must wait for a substantially higher trust profile, must be very gradual, and must be initiated while armed with a client-specific, well-researched business case. Meanwhile, if we add just a bit of discipline in a few communications areas it can greatly assist us in communications precision and bandwidth, which in turn facilitates real collaboration.

  • Any time you are planning to communicate with someone where there is a higher risk of misunderstanding, and in advance if possible, draw a picture of the information you plan to communicate and socialize it.
  • Any time you are talking about a Jira (or Rally, or whatever your favorite work manager is, here I’ll use Jira) issue or ticket, try to begin the conversation by clarifying which one you’re talking about, by number. For example, TEAM-12.
  • No email – none. Email is transient, suitable for sending someone a gentle reminder, but otherwise, all information should be in a Jira ticket, or Sharepoint location, or Jive or Confluence location (below I’ll use Confluence), or Slack/Symphony channel (below I’ll use Slack) – whatever your collaboration environment gives you access to. You don’t have tools like these? Get them. Or colocate. Your client must make at least some investment in seamless communication and collaboration.
  • ANY information about a ticket in Jira should be either in that ticket, or referenced explicitly in that ticket. A ticket/work item is about work, so ensure that the results from the work – generally artifacts and deliverables – are obvious, or referenced in the ticket.

Socialization, Team Norms and Continuous Improvement

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master
  • Required Attendees: Entire team, including Product Owner
  • Frequency: on team startup, and whenever changes to the Team Norms are needed
  • Duration: As long as it takes. The whole team dynamic is based on trust and common understanding of how we will behave toward each other.

The following is suggested. 

  1. Certain basics must be followed by the team and therefore agreed on by the whole team. This isn’t a Scrum ceremony but treat it as such, because this is fundamental to continuous improvement.
  2. On the team’s Jive page, or Sharepoint page, or the team’s persistent and highly visible repository of choice, plan to reference, and then develop and maintain, live documents briefly declaring the following items. The scrum master should invoke these items frequently to ensure consistency and high performance. They can be changed in any retrospective by the team to experiment and look for performance improvements. The team trusts each other to follow these team norms.
  3. Team name, purpose and mission
  4. Team’s Agile metrics and Business KPIs, the business level measures the team is growing for the business or organization.
  5. The product(s) for which the team is responsible, and a vision statement, roadmap outline and product architecture for each product. Geoffrey Moore’s elevator pitch is a reasonable place to start in preparing a product vision statement. A roadmap should be high level, lots of detail is probably wasted effort due to reprioritization over time. Architecture is any guidelines, patterns and constraints to be used in governing development and delivery of the product.
  6. Team’s Definition of Ready (DOR) and Definition of Done (DOD) for work items (usually user stories) that can be in a sprint. Briefly, the DOR lists the properties of a work item that must be true for it to enter a sprint. The DOD lists the properties of a work item that must be true to consider it done and be included in the actual capacity (velocity) for the team. Plenty of sample definitions exist online.

Ceremony: Daily Stand-up or Scrum

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master (initially – note that not only can anyone can facilitate a daily Scrum, but surely there will come a day soon where the Scrum Master is unavailable to facilitate) 
  • Required Attendees: Entire team, including Product Owner
  • Frequency: daily, hopefully at the same time every day
  • Duration: 15 minutes plus optional 15 minutes (or more, as team agrees)
  • Other notes: (1) recommend being strict on starting on-time, (2) if you mention a Jira ticket, include the ticket number so people can track things

The following script is suggested. 

  1. Begin: Scrum Master or facilitator begins the meeting exactly at the appointed time, or at most 1 minute late. Stragglers will quickly learn that the meeting started without them, and that others’ time should be respected. If some are routinely and unavoidably detained, then maybe a slightly different start time should be agreed on.
  2. Intro: Scrum Master introduces the meeting: This is the daily stand up for the <team name or description>. As you know, generally we stand to ensure that the meeting stays short.
  3. Announcements: S/he makes any absolutely necessary announcements. If there are more than about 2, then they should be written out and referred to instead of explicitly announced. If they don’t belong anywhere else, they can go into the meeting notes (e.g. in Confluence), or Slack, whichever is appropriate.
  4. Script: The Scrum Master scripts the meeting for today (do this each time, it is important):  I invite each of you to let us know what you did in the past 24 hours, your plans for the next 24 hours, and any frictions slowing down or impeding you or the team. Generally, please focus on collaboration. Be sure to note any people you’d like to get together and work with today or soon. We will finish this meeting within 15 minutes. We’ll offer the next 15 minute interval as a “16th minute” for anyone who would like to stay and collaborate after the official ceremony, but that is optional. Who would like to go first? Note the invitation. Let the team set the order for who speaks. Another algorithm is to ask a speaker to nominate a successor; there are several good algorithms, perhaps you can mix them up.
  5. Participants: As the Scrum Master records input into Confluence, we proceed in random order by who steps up to go next until the team members have all contributed – what I did yesterday – what I plan to do today – things slowing me down; focus on collaboration.
  6. Actions and Collaborations: Scrum Master lists actions and assigns a responsible party to each. Scrum Master lists collaborations requested and ensures that there is an agreement on both sides that they will meet.
  7. Adjournment: Scrum Master adjourns the “first 15 minutes”, the actual daily stand up.
  8. 16th Minute: Scrum Master announces, we’re now on the “16th Minute” for anyone who would like to use this time for further collaboration. It will last until <time>. I’ll stay as long as I can facilitate or otherwise be useful. The floor is open.

Ceremony: Backlog Refinement (including sizing)

  • Responsible Party: Product Owner
  • Sometimes called: Backlog Grooming (deprecated) or Story Time
  • Facilitator: Scrum Master or Product Owner
  • Required Attendees: Entire team, including Product Owner
  • Optional Attendees: team representatives from teams with strong dependencies
  • Frequency and Duration: Technically this is not even a Scrum Guide ceremony; the Scrum Guide does insist, however, on frequent performance of this activity. We recommend that a collection of 1 hour (absolute max 90 minutes) sessions be established in a rhythm and total duration such that Sprint Planning (when done without “tasking”) takes no more than 45 minutes. 
  • When: anywhere in a sprint; note that the information to be covered is relevant primarily to the next sprint. Again, establish a rhythm.
  • Other notes: (1) recommend being strict on starting on-time, (2) if you mention a Jira ticket, include the ticket number so people can track things
  • Required Preparation: DOR/Definition of Ready is ready; this is an agreed on team definition of what properties a Jira ticket must have in order to be eligible for inclusion in a sprint. Product Owner has submitted into Jira any requirements – mostly user stories – that are needed (it is ok if s/he puts in a few more, but not a lot more, during this meeting) and that most of these are roughly prioritized (“MoSCoW”)
  • Optional Preparation: even though Jira is in use, many teams ask that the Jira tickets to be considered be placed onto 3×5 cards or sticky notes for tactile use if the meeting will be held entirely in the same room. This can be a fair bit of work but can be very worthwhile. Product Owner is responsible for this.

Definition: MoSCoW: this means to prioritize using this pattern (more here):

  • M – MUST have
  • S – SHOULD have, if at all possible
  • C – COULD have, if it does not affect anything else
  • W – WON’T have this time, but would like in the future

Sizing: means to size the requirement. A Wideband Delphi, and therefore consensus-based and relative, effort sizing method called Planning Poker generally should be used. There is lots online on Planning Poker, but here are some of my thoughts:

  1. Introduction to sizing: we recommend this script to be read each time sizing is performed: When we are sizing today, be reminded that our goal is not productivity but predictability. Please keep any thoughts of time to yourself, e.g. no mention of words like days or hours. Size relative to our baseline story (be sure to identify the story). Avoid sizing aloud to eliminate biasing; use the planitpoker. If you’re in a meeting room try using a phone app. In turn, the facilitator will try to ensure that everyone has voted before the reveal.
  2. If needed, baseline sizing with a baseline story – a first story (8 points) or a small (as perceived) story (1 or 2 or 3 points). That story becomes your baseline story. The previous sentence leaves quite a bit of flexibility; the initial recommendation is that teams start with a baseline small story that is designated as a 1 point story for comparison purposes.
  3. Discuss top story on the backlog (after all, its priority is highest, from the refinement that has already been done) – PO leads
  4. ALL team members pick their estimate face down or virtual face down. The PO may participate as the team decides, but stay consistent on this; the Scrum Master should not participate, only observe. The principle is: only if you are doing development work should you participate in sizing; after all, it is that work itself that you are estimating.
  5. Show estimates once everyone has committed to a sizing
  6. Explore largest/smallest
  7. Repeat until team agrees on size for the requirement

To perform sizing across several geographies, try planitpoker.com . To perform sizing including several people in a single conference room, try one of the phones apps listed here in my blog entry on the topic.

The following meeting script is suggested.

  1. Scrum Master opens the meeting, declaring its purpose, its time box (ending time), and ensuring that all required attendees are present, in particular the PO and PM. Scrum Master should state the best understanding of the team’s current user story velocity.
  2. DOR: the Product Owner is invited to review the Definition of Ready. This should be reviewed every time.
  3. More? Scrum Master asks if any requirements need to go into the backlog; those from the PO are automatically inserted. Those from others are considered by the PO, who should let them in unless there is a very clear reason not to (e.g. it’s a duplicate).
  4. Scrum Master asks whether there are any requirements that have not been at least roughly prioritizedalready; such requirements are immediately prioritized with MoSCoW. The PO performs this prioritization while s/he is watched by everyone. Anyone can supply input to the PO during this, however the idea is to get this done quickly. If there is lots of argument, just do what the PO is suggesting and move on.
  5. Scrum Master asks for rank prioritization. Product Owner leads this. S/he rank orders the Must Haves, topmost, then next, then next, etc. All discussion is welcome, but again the idea is to be brief. If there is lots of argument over placement of a requirement, put it where the PO wants to put it and move on.
  6. Scrum Master asks for sizing. See above. Take the top requirement. Product Owner briefly describes it. Team sizes the requirement. Repeat until the Must Haves are exhausted. 
  7. Scrum Master asks for splitting. Knowing the team’s velocity, and starting at the top of the rank ordering, split any stories that should be split. The Product Owner leads this. Each resulting story should be roughly prioritized, rank ordered and sized by the team as you go.
  8. If there is time, the Scrum Master can invite discussion of the Should Haves to determine if any of them actually are Must Haves, in which case they are rank ordered as before and sized by the team as before.
  9. When you run out of time, so be it. If you need more backlog refinement, the Scrum Master facilitates getting it scheduled.

Ceremony: Sprint Planning

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master and/or Product Owner
  • Required Attendees: Entire team, including Product Owner
  • Frequency: on the first day of each sprint or as soon as possible thereafter
  • Duration: until it’s done; schedule an hour and try to be done early … ok, perhaps your first time schedule 2 hours and try to be done early

Here is a suggested script:

  1. Scrum Master ensures that the following information is conveyed: the sprint, its dates, the current vision, current roadmap, current release features, development status, architecture, previous sprints highlights as needed. This needs to be quick, but it all must be covered, every time.
  2. Show the velocity in prior sprints, preferably from a Jira-based information radiator. Team then comes to agreement on new velocity.
  3. For each team member, determine availability and resulting capacity in story points (there’s some math here for which a spreadsheet often proves convenient)
  4. Review the Definition of Done
  5. Review other definitions as needed
  6. Product Backlog review by PO, and select user stories that can be completed in sprint
  7. If user stories must be tasked, then this is the place to do it. This is a significant topic and we do not go into it at all here, other than to say we recommend that a team new to Scrum and User Stories begin by doing no tasking and see if they can make it work with nothing more than informal and frequent collaboration instead.
  8. Challenges, dependencies and risks
  9. Review capacity required, risks and mitigations, and ask for …
  10. A Commit to the forecast! (use a fist of five)
  11. Parking lot and actions
  12. Any quick plusses and deltas as a quick retrospective on the meeting

Ceremony: Sprint Review and Demonstration

It’s simple: at the end of each sprint, review your software (or systems, whatever it is that has been developed). This must include an objective demonstration of the software, a real demo; though it need not be formal it must be a real demo.

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master; not the Product Owner, as the Product Owner should focus on the Product, and receiving and approving work done as meeting stakeholder needs
  • Required Attendees: Entire team, including PO; any interested stakeholders; as many clients and/or client proxies as you can find
  • Frequency: near or at the end of each sprint
  • Duration: as long as it takes with a preference for shorter
  • Notes: many use Jira for this exercise: each user story is demonstrated in turn. Reminder: it’s not justa demo, it’s a review of what has been developed. The demo is your objective demonstration that what we say has been done, has been done.
  • Introduction: the ceremony can start with this: This is the Sprint Review. Its purpose is to review our product as it has been refined over the last two weeks, and demonstrate what we have done to our stakeholders to obtain their feedback. This is our objective demonstration that what we believe we’ve completed is done to the satisfaction of our stakeholders. In general we’ll go through the Jira items one at a time in priority order, per the script we’ve been preparing over the last few days.

Ceremony: Retrospective

At the end of each sprint, review your process.

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master
  • Required Attendees: Entire team, including Product Owner
  • Frequency: at the end of each sprint; optional: every other sprint
  • Duration: 1 hour

Suggested script: 

  1. Introduction, including the ceremony stop time. Here is a good script for the introduction that includes Norm Kerth’s prime directive: This is our retrospective, where we evaluate and experiment with our development and delivery process with intent to improve. Regardless of what we discover today, we understand and truly believe that everyone did the best job s/he could, given what was known at the time, his/her skills and abilities, the resources available, and the situation at hand. Our purpose here is continuous improvement, to become more skilled and higher performing as a team over time. We will end this session at ____.
  2. A framework is set up for the retrospective. There are many available, for example search for “10 retrospective styles” online. Here is one often used early on: Scrum Master asks for each person attending 
    1. to write down 3 things that went well
    2. to write down 3 things that could use improvement
    3. to prioritize each set

Stickies can be used if everyone is in the same room – one item per sticky note.

  • Each person articulates to the group attending their top went-well item – skipping those already covered
  • Ditto improvement suggestions
  • Scrum Master records actions as we go
  • Suggestions for improvement are prioritized
  • Each is placed into a Process Improvement Backlog
  • The Scrum Master ensures that the top two are assigned volunteer owners in Jira