We’ve all heard the maxim change is difficult. The reasons that change is hard are far too numerous to discuss in a single blog posting. My intent here is to specifically focus on organizational agile transformations and the difficulty of changing culture. Additionally, I want to leave you with some hope. While it is difficult, it is not impossible. There are steps that you can take as an individual that can help the organization as a whole move in the right direction.
The 2013 VersionOne State of Agile Survey indicates the top three reasons cited by practitioners for adopting agile within their organizations include accelerated time to market, the ability to more easily manage changing priorities, and to better align IT and the business, respectively. These are desired results. Unfortunately, viewing agile as a methodology alone will only minimally achieve these results, if at all. The same survey cited the primary barrier to agile adoption as being the inability to change organizational culture.
Many adoptions focus primarily on providing training for individuals and teams. Training is certainly crucial; unfortunately, many initiatives stop with training. This is insufficient to sustain the change effort’s momentum. It’s perplexing to me that organizations expect a shift in results with training alone? It’s unrealistic. Even when training is provided the attendees are thrust back into an environment that does not support new experiences that validate a new way of doing things. The pyramid in the illustration below helps to visually explain why.
First, I have to give credit for this illustration to Heather Hassebroek. I met Heather only briefly at an agile conference, where we sat next to each other and started a discussion about why we think change is so difficult. I think the pyramid succinctly demonstrates what’s occurring. She jotted it down and I asked her if I could use it. She graciously said yes. Thank you Heather!
Our experiences lie at the base of the pyramid. These experiences create and reinforce our beliefs and values, which drives our actions and behaviors. The actions and behaviors produce results—both good and bad. Therefore, one of the keys to transformation efforts is that it has to be rooted in individual experiences that breathe life into the new way of doing things.
For example, let’s consider the agile principle that states the primary measure of progress is working software. To realize this principle we must first provide experiences that reinforce new values. I have worked with teams that have attended training and seem to understand the principles of The Agile Manifesto very well. The mindset just seems to make sense to them. Yet, when returning to the day-do-day routine of their projects they fail to have stakeholders attend sprint reviews and are required to provide weekly project status reports including percent complete and red, amber, green stoplight indicators. The team’s collective experience is that working software isn’t really valued as much as a status report. This repeated shared experience leads to apathy and stalled transformations. Alas, the team and organization continues to slumber under the status quo.
Here are 5 new experiences to consider if you want to foster an agile culture. The list isn’t exhaustive, of course, but all of these are steps to consider if you want to reinforce new values and drive behavior change leading to positive results.
- Expect working software to be demonstrated at the end of a sprint. If it can’t be demonstrated, it’s not done.
- If you need something from someone—call them! Better yet, if you are co-located walk over to them and have a conversation and engage them in collaboration.
- If you’re a manager or executive, form stable teams. If you do not understand the long-term competitive advantage of a high-performing stable team, you have much to learn about agile organizations.
- Be open about your failures at all levels (individual, departmental, managerial, etc.). This has to start with you! Don’t expect everyone to be open first. You must demonstrate this behavior. But consider this in a positive light. Also be open about what you learned as a result of the failure. Over time, this will help foster a learning culture. Consider a team-level sprint or release award for the failure that led to the most learning.
- Experiment with pairing for 5 days. I’m not simply referring to pair programming. Try pairing in daily activities. You may be surprised at the results. If not, it’s only been for 5 days. But give it at least that much time. If it works you might even consider rotating pairs every week to help drive learning and building relationships.
Wie beschreibst du deinen Eltern/ Freunden deinen Arbeitsalltag bei Boris Gloger Consulting?
Viele verbinden mit Unternehmensberatung gut gekleidete Menschen, viel reisen, Überstunden en masse und schöne PowerPoint-Foliensätze. Im Wesentlichen stimmen einige dieser Aspekte, doch ich denke, dass es bei Boris Gloger Consulting doch ein wenig anders abläuft als in klassischen Beratungen. Meiner Familie und Freunden beschreibe ich meinen Arbeitsalltag immer als äußerst abwechslungsreich und herausfordernd. In der Hauptsache bin ich dazu da, anderen Menschen zu helfen, ein Produkt erfolgreicher zu entwickeln. Dazu verwende ich moderne Ansätze, die in vielen Organisationen Widerstand hervorrufen. Auch das ist ein Grund, warum ich mit an Bord bin. Neben den Projekten beschreibe ich meinen Freunden auch oft unsere differenzierte Arbeitsweise im Unternehmen selbst, etwa das Prinzip der Freiwilligkeit oder den Freiraum, der uns gegeben wird. Viele können das nicht nachvollziehen, weil sie nicht glauben können, dass eine Firma auf Basis dieser Prinzipien funktionieren kann.
Welchen Beruf wolltest du als Kind unbedingt ergreifen?
Als Kind wollte ich die klassischen Abenteuer-Berufe wie Feuerwehrmann oder Polizist ergreifen. Vielleicht war es aber auch die Hilfsbereitschaft, die mich dazu motivierte. Ich denke, dass ich mit meiner Berufswahl als Consultant diese Wünsche zumindest teilweise ausleben kann. Immerhin ist jedes Projekt immer wieder ein Abenteuer und ich liebe es, anderen Menschen zu zeigen, dass sie ihren Arbeitsalltag erleichtern und gleichzeitig erfolgreich sein können.
Wie siehst du deine bisherige Karriere? Viel Zufall oder überwiegend sorgfältige Planung?
Meine bisherige Karriere war überwiegend sorgfältig geplant. Ich habe bereits kurz vor meiner Matura (Abitur) den Entschluss gefasst, gleichzeitig einen verantwortungsvollen Job anzunehmen und mein Studium am Abend und Wochenende zu absolvieren. Fünf Jahre später bin ich froh, diesen Weg gewählt zu haben. Ich erkenne, wie viel Vorsprung ich durch meine zusätzlichen fünf Jahre Berufserfahrung nach meinem Studienabschluss hatte oder noch immer habe. Auch der Weg ins Consulting war geplant, da ich nach fünf Jahren im gleichen Unternehmen „raus“ in die weite Welt und „Neues“ kennenlernen wollte. Da mich agile Methoden bereits im letzten Unternehmen und auch während meines Studiums fasziniert haben, fiel die Wahl auf eine Unternehmensberatung mit Fokus auf agile Methoden und dann letztendlich auf Boris Gloger Consulting.
Gibt es ein bestimmtes Ritual in der Arbeitswoche, auf das du nicht verzichten könntest?
Interessanterweise habe ich bei dieser Frage als Erstes den Weekly Report, den wir dem Kunden zu Abschluss der Arbeitswoche schicken, im Kopf. Für mich ist dieses „Absenden“ der formale Abschluss der Projektwoche, mit dem ich meine Gedanken für das Projekt zum Wochenende ruhen lasse.
Unter all den Projekten, die du für Boris Gloger Consulting realisiert hast: Welches ist dein All-Time-Favourite?
Ich hatte erst ein Projekt bei Boris Gloger Consulting, das ich nun bereits seit mehr als sechs Monaten begleite. Ich denke aber, dass es durchaus einer der All-Time-Favourites werden könnte. Die große Herausforderung in dem Projekt waren die sehr unterschiedlichen Typen und Charaktere (Entwickler, SAP-Berater und Anwender), die erst zur Zusammenarbeit bewogen werden mussten. Es war großartig zu sehen, wie diese Entwicklung über den Lauf der Sprints zunehmend stattgefunden hat, so dass wir nach ein paar Monaten ein hoch performantes und gut zusammenarbeitendes Team geschaffen haben.
Drängende Kundenanfragen, E-Mail-Flut, Meeting-Marathon oder als Consultant jeden Tag an einem anderen Ort: Was ist dein Geheimrezept, um im hektischen Arbeitsalltag einen kühlen Kopf zu bewahren?
Bereits während meines Studiums, das ich neben meinem 40-Stunden-Job absolviert habe, habe ich mir angewöhnt, ein gutes Zeitmanagement zu betreiben. Dazu gehört neben einer ordentlich gepflegten To-Do-Liste auch die richtige Einstellung bzw. Herangehensweise. Ich versuche beispielsweise, alle Aufgaben so früh wie möglich abzuschließen, auch wenn die Deadline noch weit entfernt scheint. Das hilft mir, nicht zu sehr in Stress zu geraten, wenn diese Termine näher rücken. Zusammengefasst ist mein Rezept ein strukturiertes und zeitnahes Abarbeiten der zu erledigenden Themen.
Was ist für dich das Besondere an der Arbeit bei Boris Gloger Consulting?
Das Besondere ist einerseits das Projektumfeld, das äußerst spannend und herausfordernd ist. Immer wieder gibt es neue Projekte, in denen man am liebsten selber mitwirken will, weil das Problem oder die Situation einfach nur aufregend und spannend ist. Andererseits ist es die Atmosphäre im Unternehmen selbst. Alles basiert auf Freiwilligkeit und jeder kann sich einbringen, wo er seine eigenen Stärken sieht, solange es zum Unternehmensziel beiträgt. Dieser Freiraum ist anfangs ungewohnt, auch ich habe ein paar Wochen bis Monate gebraucht, um mich damit zurecht zu finden. Nun bin ich in vielen Themen engagiert und weiß, wo ich zu den Unternehmenszielen beitragen kann und das auch tue.
Gibt es eine Marotte, mit der du deine Kollegen regelmäßig auf die Palme bringst?
Da ich ein sehr ruhiger und friedliebender Mensch bin, sind es wenn nur kleine Marotten, wie beispielsweise meine Penibilität beim Review von Blogbeiträgen, in denen ich regelmäßig viel in der Wortwahl und Satzstellung ändere.
Was machst du in deiner Freizeit, um runterzukommen?
In meiner Freizeit verbringe ich viel Zeit mit meiner Lebensgefährtin, auch weil wir uns unter der Woche nicht bzw. äußerst selten sehen. Dabei stehen nicht außergewöhnliche Hobbies, sondern einfach die gemeinsame Zeit im Vordergrund. Das heißt, wir unternehmen total unterschiedliche Dinge und gerade das, worauf wir spontan Lust haben. Gerne komme ich aber auch allein „runter“, meist bei sportlichen Aktivitäten wie Rad fahren, Snowboarden oder Tauchen.
Scrum ist für mich…
die perfekte Methode, ein großes Vorhaben strukturiert und erfolgreich zum Ziel zu bringen und zugleich das Team zufriedener mit seiner Arbeit zu machen.
- Es liegt an dir, was du aus der Arbeitswelt machst
- Wie viel bin ich wert? Die Geschichte einer User Story
- Erinnerung: Scrum Breakfast diesen Samstag im Quadro!
(Guest blogger and Rally user Erine Gray is the founder of Aunt Bertha, a software platform that makes it easy for people to find and apply for food, health, housing and education programs in the U.S.)
This is the story of how Aunt Bertha used Rally to get our team organized, communicate better, and start loving each other again. It was kind of like group therapy.
I’m only sort of joking. Our team doubled in size this year and there are now more people writing code. There’s more knowledge to be transferred. There’s more testing that needs to be done. There’s more that can go wrong. And things did go wrong; like any relationship, communication is key.A Story
We had a new customer, Critical Mass, who wanted its users to be able to know if they qualified for a local cancer program using rules common in the cancer program space: current age, age at diagnosis, type of cancer, and current stage of cancer. We’ve always had ways of determining whether someone qualified for a program based on their income, but we didn’t have an easy way to extend this qualification to other eligibility rules, like these.
Ideally, a cancer survivor should be able to see—with the click of a button—whether or not they qualify for a cancer program, and why. They should be able to see something like this:
Since Aunt Bertha’s mission is to make program information accessible, we were excited to build this feature into our product. However, we had a problem.Teamwork and Knowledge Transfer
When we first started using Rally at Aunt Bertha, we had two new programmers on the team. I was the lead developer, and I was terrible at knowledge transfer. Release after release would go by and features were not delivered on time. And it was my fault.
I had no doubt in my mind this feature should be built, and I knew how I was going to do it. I had a vision of what it was supposed to look like and a rough idea of how the algorithm would work, since I’d written most of the search code over the last three years.
The trouble was that building this feature was going to be a significant amount of work, and I didn’t have time to build it. Programmers are typically optimistic about how long it takes to do stuff, but we have short memories. It’s kind of like golf: we only remember those great drives that lay up perfectly on the fairway; we don’t remember the time we spent digging through the weeds to find our ball (or the late nights spent debugging only to find out we put a semicolon in the wrong place.)
Aunt Bertha was also in a growth phase. I didn’t need to be the lead programmer anymore. I had to delegate, but I was afraid because I knew that this feature would touch hundreds of lines of code that only I understood.Enter Rally
Around this time our product manager, Ruby, started implementing Rally for our software development process. Prior to Rally, we had used Github as a code repository and for issue tracking. It was a nice, lightweight way of keeping track of issues and milestones, but now we had more developers and staying organized was a real challenge. We needed more rigor and structure.
I didn’t know much about agile software development. Ruby implemented a bi-weekly sprint planning meeting, and gave us all homework. Our job was to look at all of our stories, and break them down into digestible tasks.
I took the Critical Mass eligibility rule story and began to break it down. In the past I would typically jump into a feature, only to discover later just how complex it was. Breaking down a feature into stories and tasks really forced me to think about the problem in small chunks. That was when the light bulb went off in my head: I could indeed delegate some of these tasks to our new developers. I didn’t have to be the one to do it all; I just had to coach them along.
I’m happy to report we built a pretty amazing feature that’s making it easier for cancer survivors to navigate the myriad programs out there. Our developers can now dig into the most complex code, and I can now concentrate on getting new customers and setting the longer-term vision for the product.
Rally helped us communicate better, and set deadlines that we could actually make. Rally helped us understand that big problems are nothing but a series of small problems.Making It Fun
One of my favorite views in Rally is the Story Estimation screen.
After we’ve developed our stories and added the requisite tasks, our next step is to estimate about how long a story (or feature) will take to build. This screen allows you to easily drop in a story by the estimated size. We size ours based on the size of our dogs (we’re a dog friendly office.)
A small story is a “Cinco.” A “Rosie” (that’s my dog) is a medium-sized story. A “Beowolf” (Chris’ dog) is a big story.
Cinco, Rosie, and Beowolf represent small, medium, and large story sizes
It may seem silly to estimate your workload this way, but the truth is that sizing is relative. What matters is how many Beowolfs, Rosies, or Cincos you can accomplish in a two-week sprint.Why We Chose Rally
We considered plenty of options: we could have just stayed with Github, and we looked at Rally competitors. But we ended up going with Rally for a couple of reasons. One reason was that Rally offers its products at a discount for fellow B Corporations (Aunt Bertha has been a B Corporation since 2011.) The primary reason, however, was an encounter I had with Rally’s founder, Ryan Martens.
Ryan was a mentor at Boulder’s Unreasonable Institute, and when Aunt Bertha went through the 2012 Unreasonable Institute in Boulder, I had a chance to interact with Ryan. During that summer the team would spend most evenings with mentors: getting our questions answered, hearing about their experiences, or just sharing stories. I distinctly remember one of Ryan’s comments on business and ethics: the passion of his delivery and his desire for our success made me a fan immediately. Simply put, he seemed like a guy I wanted to be like, someday. And Rally is a company we want to be like someday.Erine Gray
It’s a great day: you wake up, the sun is shining, there is no traffic on the way to work, and when you get to the office… there it is. A shiny, new, fully sanctioned project. It’s GO TIME!
Easy there, killer. Before you dive in head first, let’s take a step back and get our proverbial ducks in a row.
All too often with agile-run initiatives or projects, we skip the foundational efforts that set the team up for success. In business environments where teams are constantly challenged to do more, faster, and with less, these foundational efforts are often overlooked. However, this quick-to-launch mentality ends up costing us much more, further on down the line.
What are these foundational efforts that we speak of? Let’s take a step back to bootcamp and remember the importance of:
- Product Vision
- Product Roadmap
- User Roles
- Initial Backlog Population
- The Architectural and UX Runway
Three Preconditions for Starting Work
No one embarks on a new effort, initiative, project, or body of work with the intent to fail. However, agile development is often used as an excuse to make it up as you go along. Let’s frame up the goal of foundational work for agile workstreams by creating a user story.
1. Business Readiness: The degree to which business stakeholders are in alignment on what the vision is, who it is intended to benefit, and how much money should be investing in realizing the value.
2. Architectural Readiness: Ensuring that key IT stakeholders understand the vision and target scope for the effort as well as the definition of a high-level architectural approach to delivering value.
3. Team Readiness: Critical collaboration activities and workshops necessary to prepare the team for an incremental delivery cadence.
The business defines the ‘what’ for an agile team; therefore, readiness on behalf of the business is of paramount importance before engaging the technology group. But what does business readiness look like?
Business Case: Defining the Need
The business case provides justification for funding a new initiative. Depending on your organization, this could be something as simple as an elevator pitch, or a much more detailed document outlining market opportunities, value propositions, return structures, etc.
Regardless of the level of detailed that is needed, having a clearly documented business case helps build a shared understanding of value among executives, sponsors, and key stakeholders. Continued support from these individuals is as key to the product launch as is the technical solution. See Figure 1 for an example of the Elevator Pitch Structure.
FIGURE 1: Elevator Pitch Structure
With the business case crafted, the next task is to develop a cornerstone for the team to focus on. This cornerstone, or product vision, serves as the high-level focus from which every epic, every feature, and every user story is created. All work done by the agile team should be focused on satisfying the product vision.
The vision should be comprised of the product name, a value statement, and a few key features that differentiate the product. The vision may also outline some basic technical requirements such as OS compatibility or platform such as “web-based.”
FIGURE 2 – Design the Box
While it is important for the product owner and key stakeholders to understand and align on the vision when preparing to kick-start the initiative, keep in mind that it will be necessary to have a vision workshop with the cross-functional agile team in order to ensure a shared understanding of the product they are building. Once created, the product vision should be posted in a common team area to serve as an information radiator. The vision will help keep the team focused throughout the work cycle.
The product roadmap helps link the product vision to the work which agile teams do every day. The roadmap is not intended to be a commitment or project plan, but simply a guide that the agile team uses to plan their work during release planning sessions.
Without a roadmap, teams are left without a clear strategic vision. It is a common misconception that agile teams do not strategize. The reality is that agile teams are highly strategic and nimble enough to shift focus with rapidly changing market conditions.
FIGURE 3 – Product Roadmap
The roadmap focuses on high-level themes, epics, or features – and, like the backlog, remains fluid throughout the course of the initiative. To be effective, the artifact should be highly visible and referred to often. As market conditions and priorities change, so should the roadmap and other downstream artifacts. Again, aligning on the roadmap before engaging the agile team is critical in order to avoid swirl and confusion when getting the team started. It is important to ensure that business stakeholders understand that the roadmap will most certainly evolve as the team begins work.
With the ‘what’ defined in the business case, product vision, and product roadmap, it is now time to consider the ‘who.’ The definition of user roles seems like a fairly straightforward task, but once the discussion begins, teams are often surprised at how difficult the task can be.
Consider Facebook. On first thought it may seem simple: New User, Existing User, Administrator. Not so fast. Really think about all of the different interactions that take place on Facebook.New User Existing User Business User Group Administrator Advertiser Photo Poster Marketplace User Under 13
And that’s not even scratching the surface!
Now consider any system within your organization and imagine how challenging it would be to identify all of the different paths and user types within the system. Consider the importance of evaluating the individual needs of each of these users in creating a solution.
Remember, one of the key benefits of an agile culture is the delivery of high-quality, customer-focused software. If the team is not sure who they are solutioning for, it is likely that the product will not sufficiently satisfy the needs of anyone.
Baseline User Stories & The Backlog
With the product and users now defined, it is time to elicit basic needs from our business partners. Remember, the business product owner (BPO) is the tip-of-the-spear for all things business. The BPO serves as the single voice for the customer, product management, sales, marketing, legal, finance, and all of the other organizations that make up the business function. The BPO and supporting team need to elicit baseline user stories from each of these groups and place them on the backlog for prioritization.
As the program progresses, the BPO will be accountable for making sure any inputs from the business team are ready for the agile team at the appropriate time. A few examples of these items may include legally approved verbiage, approved graphics from the marketing team, and any special promotional offers from the sales team. The BPO, with full control over the prioritization of the backlog, must maintain awareness of upcoming user stories and their dependency of these inputs.
Now that we understand the ‘what,’ it is time to engage the technology group! HOLD ON… let’s tap those brakes! You’re only partially right. With the ‘what’ defined, we still have not begun to explore the solution. To begin framing up the ‘how,’ we need to engage the solutions architect.
Developing Shared Understanding
The solutions architect is in a unique position to begin bridging the gap between business need and technology execution. This individual has a broad view of all technology groups, infrastructure types, and data locations. In bringing the architect in early, the business will be able to get an accurate gauge of the technical feasibility of their ask, as well as the level of effort involved to deliver.
Identify IT Impacts
Once the feasibility study is complete, the solutions architect will start to map out the solution. This sketch will include the identification of new infrastructure, data flow mapping, and systems impacts. With this analysis complete, leaders can determine the right skill sets and organizational units that need to be involved in forming the agile team(s) who will work on the initiative.
Let’s assume you’ve followed a good plan for initiating this new body of work. Your product owner is firing on all cylinders, business stakeholders are in alignment and engaged, the architects have a vision for the solution needed to deliver value, and the cross-functional set of agile team members are locked and loaded. Please, please, please — don’t make the assumption that those folks are clairvoyant and have a shared understanding of what the organization is looking to achieve!
Agile teams need to practice the full Five Levels of Agile Planning [See Figure 4]. It doesn’t mean the product owner and business stakeholders do Levels 1-3 and the team only engages in Levels 4-5. The entire agile team plus key stakeholders need to collaborate in order to prepare for the first sprint planning event. Highly effective agile teams engage in Levels 1-3 of planning during a timeboxed period often called Sprint Zero. When well-facilitated, it could take only a week, but spending more than four weeks on these activities would likely lead to analysis paralysis. Key preconditions, activities, and outcomes of Sprint Zero are outlined in Figure 5.
FIGURE 4 – Five Levels of Agile Planning
FIGURE 5 – Sprint Zero Summary
Start Small & Improve Incrementally
Feeling overwhelmed? If you’ve got a gap in your pre-planning processes or you’re currently feeling the pain associated with a lack of readiness in one of these three areas, consider one of these three techniques in order to improve. After that, make a backlog of all of the opportunities to improve your pre-planning processes, prioritize the list, and affect change incrementally over time.
1. The Stakeholder Engagement Cadence
Product owners are intended to be the single source of truth around ‘what’ the agile team needs to deliver. In order to effectively do this, product owners need to fully understand their stakeholders and proactively engage them so that priorities and acceptance criteria are the best quality possible.Figure 6 outlines a framework for a stakeholder engagement cadence where stakeholders are classified into one of three groupings (Advisors, Supporters, or Sponsors) and then, based on the classification, are brought together once a month, twice a month, or weekly, based on their level of involvement in the workstream. To learn more about this technique, check out Proactive Stakeholder Engagement, a post on Davisbase’s #BecomingAgile blog.
FIGURE 6 – Stakeholder Engagement Cadence
2. The Backlog Refinement Cadence
It is essential that teams keep a product backlog deep enough to sustain incremental delivery. While pure Scrum doesn’t call for teams maintaining a runway of “ready” stories or a projection of the backlog items they will be completing in which sprint, in practice – it is a useful planning approach for keeping flow within the system and aligning the dependencies and coordination points that often exist within organizations of scale and complexity. Figure 7 outlines a backlog refinement approach that creates focus for agile teams and helps build the discipline to keep one sprint’s worth of stories in a “ready” state, as well as get the details and specifications just enough in advance of the sprint where they will commit to the work. When paired with the Stakeholder Engagement Cadence, this information radiator can also be useful for creating context on topics for collaboration. To learn more about the cadence for backlog refinement, check out the #BecomingAgile Webinar recording Strategies for Grooming Your Backlog.
FIGURE 7 – Refinement Cadence
3. The Architectural Feedback Loop
In a similar manner to how feedback is generated often in software demonstrations, it is equally as important for feedback to be passed on the to architect. On an agile team, the solutions architect is working six to eight weeks ahead of the development team laying down the architectural runway. If the development team finds that some elements of the architecture are either missing or not working, it is important to pass that information along to the architect on a regular basis in order to correct the issues in upcoming iterations.
As a result of this feedback loop, many technical and architectural user stories will begin to appear on the backlog. These elements can appear either on a product backlog in the case of tactical changes, or as the Scaled Agile Framework® (SAFe™) tells us, enterprise changes may appear on the program backlog.
FIGURE 8 – Architectural Epics
Please comment on this post and keep the conversation going. We’re constantly looking for better ways of doing things and get excited by helping others with #BecomingAgile. Learn more by checking out these additional resources:
- Scrum Process Overview & Guide to the Five Levels of Planning
- The #BecomingAgile Webinar Series Archive (each worth 1 PDU)
- An Online Agile Glossary of Key Terms & Definitions
About the Authors
Adam Mattis and Leslie Morse are colleagues at Davisbase Consulting and, combined, have over 29 years of experience delivering value with software and information systems.
Adam is a program manager by trade residing in Nashville, TN. He spends most of his time working with new teams adopting agile practices. You can reach him at firstname.lastname@example.org or on Twitter @AgitatedAgilist.
Leslie is a business analyst by trade and resides in Columbia, SC. Most often she engages with organizations initiating agile transformations. You can reach her at email@example.com or on Twitter @lesliejdotnet.
To clarify, the members of the PO teams are mainly populated by a Product Owner (Product Lead) and facilitator (could be a Scrum Master), but from there we’ll include others like a development lead, a testing lead, and an architect. We use the team construct over a single person because we’re operating at scale, with multiple delivery teams. The Leads and Architects are thinking bigger-picture strategy and are aware of external dependencies that need to be avoided or dealt with. The goal is to progress work along, getting it ready for the delivery team. To help bridge the knowledge gap with the delivery teams, there are members of the delivery teams who will attend the progression workshops, mostly to play the part of the Napoleon Corporal. (I call them that, not the client)
For those unfamiliar with the term Napoleon Corporal:
Napoleon recognized how vital it was to have an enlisted soldier in the planning process. During every Battle Plans briefing Napoleon would have a Corporal shine his boots knowing that the Corporal was listening. Once the General Staff finished the brief, Napoleon would look down at the Corporal and asked if he understood the plan. If the Corporal answered, Yes Sir! The General would have his Staff execute the plan. If the Corporal answered, No Sir! The General would have the General Staff rewrite the plan.
It doesn’t matter if you’re doing textbook Scrum or something at scale. Your people still need a shared understanding. If not, you’re going to start seeing a lot of delays and a lot of rework.
When you have a Scrum or Kanban team, you’re not always getting “A” players. Sometimes it’s a real mixed bag. To expand the military metaphor, sometime you don’t get a Corporal. Sometimes, you get yourself a Boot Private. If work is outsourced, developers and testers won’t necessarily have domain experience. They might be great coders or testers but not experienced in financial, medical, or other verticals. You need to get them to understand the mission and the mission is not necessarily to write and test code. The shared understanding is how to solve a problem for the customer.
Depending on the experience of the delivery team, the conversation (and backlog) may need to be simplified enough to be understood by someone junior to a Corporal.
When I was in Israel a couple of weeks ago teaching workshops, one of the big problems people had was large stories. Why was this a problem? If your stories are large, you can’t show progress, and more importantly, you can’t change.
For me, the point of agile is the transparency—hey, look at what we’ve done!—and the ability to change. You can change the items in the backlog for the next iteration if you are working in iterations. You can change the project portfolio. You can change the features. But, you can’t change anything if you continue to drag on and on and on for a give feature. You’re not transparent if you keep developing a feature. You become a black hole.
Managers start to ask, “What you guys doing? When will you be done? How much will this feature cost?” Do you see where you need to estimate more if the feature is large? Of course, the larger the feature, the more you need to estimate and the more difficult it is to estimate well.
The reason Pawel and I and many other people like very small stories—size of 1—means that you deliver something every day or more often. You have transparency. You don’t invest a ton of work without getting feedback on the work.
The people I met a couple of weeks ago felt (and were) stuck. One guy was doing intricate SQL queries. He thought that there was no value until the entire query was done. Nope, that’s where he is incorrect. There is value in interim results. Why? How else would you debug the query? How else would you discover if you had the database set up correctly for product performance?
I suggested that every single atomic transaction was a valuable piece. That the way to build small stories was to separate this hairy SQL statement was at the atomic transaction. I bet there are other ways, but that was a good start. He got that aha look, so I am sure he will think of other ways.
Another guy was doing algorithm development. Now, I know one issue with algorithm development is you have to keep testing performance or reliability or something else when you do the development. Otherwise, you fall off the deep end. You have an algorithm tuned for one aspect of the system, but not another one. The way I’ve done this in the past is to support algorithm development with a variety of tests.
This is the testing continuum from Manage It! Your Guide to Modern, Pragmatic Project Management. See the unit and component testing parts? If you do algorithm development, you need to test each piece of the algorithm—the inner loop, the next outer loop, repeat for each loop—with some sort of unit test, then component test, then as a feature. And, you can do system level testing for the algorithm itself.
Back when I tested machine vision systems, I was the system tester for an algorithm we wanted to go “faster.” I created the golden master tests and measured the performance. I gave my tests to the developers. Then, as they changed the inner loops, they created their own unit tests. (No, we were not smart enough to do test-driven development. You can be.) I helped create the component-level tests for the next-level-up tests. We could run each new potential algorithm against the golden master and see if the new algorithm was better or not.
I realize that you don’t have a product until everything works. This is like saying in math that you don’t have an answer until you have the finished the entire calculation. And, you are allowed—in fact, I encourage you—to show your interim work. How else can you know if you are making progress?
Another participant said that he was special. (Each and every one of you is special. Don’t you know that by now??) He was doing firmware development. I asked if he simulated the firmware before he downloaded to the device. “Of course!” he said. “So, simulate in smaller batches,” I suggested. He got that far-off look. You know that look, the one that says, “Why didn’t I think of that?”
He didn’t think of it because it requires changes to their simulator. He’s not an idiot. Their simulator is built for an entire system, not small batches. The simulator assumes waterfall, not agile. They have some technical debt there.
Here are the three ways, in case you weren’t clear:
- Use atomic transactions as a way to show value when you have a big honking transaction. Use tests for each atomic transaction to support your work and understand if you have the correct performance on each transaction.
- Break apart algorithm development, as in “show your work.” Support your algorithm development with tests, especially if you have loops.
- Simulate in small batches when you have hardware or firmware. Use tests to support your work.
You want to deliver value in your projects. Short stories allow you to do this. Long stories stop your momentum. The longer your project, and the more teams (if you work on a program), the more you need to keep your stories short. Try these alternatives.
Do you have other scenarios I haven’t discussed? Ask away in the comments.
2007 – I had been working for several years as a traditional Project & Program Manager in the .com division of a Fortune 500 company. There was a constant cloud over my head. I didn’t really enjoy my work and had been soul searching for some time. I had been exploring and reading a lot about better ways to get work done, and came across this thing called Scrum. So I signed up for a CSM class, took it, was enlightened, and excitedly told my Director all about it. He gave me the green light to try it out on a small project or two, which I did. Somewhat surprisingly, these two projects were wildly successful. The productivity was more than triple the traditional Waterfall projects, the number of defects introduced was almost zero, our customers loved the quick feedback and the ability to change their minds whenever, and the buzz was that this was actually something fun to be a part of.
I was quickly named as the Lead Scrum Master, Coach, and Trainer for all things Agile, as I was the only one who knew anything about this stuff at the time. Others started inquiring about getting on one of these Scrum teams, how they could get training, how to get started, rooms, projectors, supplies, tools, etc.. I recruited some help, and we made incremental progress, getting more and more traction as we went along. It was very cool to be part of something like this. That’s not to say everything was perfect; it wasn’t. Our PMO still managed scope poorly, jamming too much work into a small pipe. Alignment at the Program and Portfolio levels wasn’t really there yet. Not everyone wanted to be part of a Scrum team, which we just kinda assumed they would. The culture held us back in certain areas. Not all the Management level was on the same page. We didn’t have any budget for external training, which is why they used me; I was ‘free’. But at the end of the day, enough folks were convinced this was something that was valuable that we expanded the initiative.
2011 – I made the decision to leave the big company I had been working for to become an Agile Consultant at a small Midwest consulting firm in their Agile practice. It was an exciting time for me personally. I thought I’d be able to work with different clients, and help them do the same thing I did in my previous experiences. The opportunity for growth appeared to be huge. But as time went on, the work turned out to be intermittent at best, and we were struggling to gain any new business. Building up an Agile practice is not only hard work, but takes time, money and patience. The hard work part of the equation we had, but the rest was pretty limited. Once my 6 month Agile consulting engagement with our one and only customer was completed, I found myself in a bit of a pinch. We didn’t have another client for our Agile consulting services, and in order to stay on with the firm, I had to take whatever came my way. In this case it was a traditional Project Manager position with an insurance company. And yes, they utilized the Waterfall method of getting work done. The fact that I had a PMP after my name, and several years of good experience qualified me for the interview, which I passed. I needed the work, and so did my firm. The hourly rate was good, so I took it. I would soon come to find out what a nightmare I was in for.
It had been years since I last managed a Waterfall project, and those memories were less than fond. So I brushed up on my MS Project skills, dusted off the old PMBOK, reviewed the organization’s procedural guide for project management, and talked with some of the other PM’s at this new organization I’d be working with. None of them seemed too thrilled with their jobs, which was a red flag that I chose to consciously overlook.
First week at the new gig was fine. Pleasantries, meeting the players, getting comfortable, reading procedural manuals, software downloaded, all that stuff you do the first few days. Then I got assigned as the Project Manager for three projects (one new and two in-flight). I was gung-ho and ready to show them what a great Project Manager they just hired. I was expected to manage the schedule, cost, and resources, which were all fixed. I would soon come to find out that this was not the case, but not in the way you might think. Managers would intermittently pull resources from in-flight projects to work on other higher priority projects or bug fixes, with the same expectations of us finishing the contracted scope and time deadlines for the projects. Of course, the beautifully constructed Gannt charts went down the toilet. I spent way too much time fighting for resources, adjusting the schedule, dealing with a multitude of dependencies, and discovering issues and impediments much too late. As each project team member was working on an average of 4 projects simultaneously, context switching was through the roof. The ‘throw it over the wall’ mentality was well established. There was a rush to get tasks completed on one project and move on to the next project. Back and forth, ad infinitum. Waste, frustration and technical debt; a vicious and unhealthy cycle that just dug deeper holes. I was also the person in between the customer and the team, and as such, was required to know everything, all the time, and communicate it all to everyone at least once a week in a high stakes status meeting where key team members would often either not show up at all, respond to emails on their phones if they did, and the internal customer would freak out about dates, scope, cost and risks. They didn’t want to hear about reality. Needless to say, those status meetings were hell. I was constantly on the hot seat, folks waited to be told what to do and when to do it, and when things fell down, the finger was squarely pointed at me, the Project Manager. This was not natural and it wasn’t working. The concept of a true Team was missing. It seemed that folks didn’t care about one another or the success or failure of the projects. I talked with a couple of my peers about their experiences, and while they recognized the same situation privately, they were not willing to call things out publicly. I presume this was based in fear. That cloud sitting over my head had returned. I knew the situation wasn’t sustainable, but I kept on for another couple of months anyway. It got to the point where my mental health was worth more than a paycheck, so I respectfully resigned. But just before I did, I had a chat with the Director of the Project Management Office. I talked with him about Scrum, and all the ways it could change things for the better, even in a regulated environment with hard completion dates. I explained it would be a big effort to transition to Agile. And that it wouldn’t happen overnight. That it would require investment. But over the long term, it was the smart thing to do and absolutely necessary to remain competitive. He listened, but wasn’t interested at the time. Too much critical stuff in flight to introduce such a change at the moment. Maybe later, he said. So that was it. At least I had tried.
2012 – Happy ending to this story… I soon landed an Agile Coaching gig with a larger consulting firm on the east coast, shortly after the aforementioned Waterfall debacle. The client was open to new ideas and eager to transform their organization to Agile/Scrum/Lean/XP practices. We made a lot of headway by investing in people, teams, training, Agile Business and Technical Coaches, various tools, and open collaborative spaces. Upper and middle management created a culture of trust and transparency, and became true servant leaders to the teams. The business side began working closely with the technical side. No more throwing stuff over the wall and moving on to something else. We would succeed or fail as a team, not as individuals. Huge changes in a short period of time, yielding huge gains in productivity, efficiency, and quality. And most importantly, we gave the customer what they needed, not what they asked for 9 months ago. Customer involvement throughout was one of the key factors of this success.
During my tenure as an Agile Coach at the aforementioned consulting firm, we chose VersionOne as our ALM tool. A VersionOne Coach and Product Consultant came in and helped us to configure the tool to fit the client’s organizational structure, showed us how to administer it, and trained a large group of IT and business folks on how to use it over the course of about two weeks. I got to know this VersionOne dude. We worked together on a few issues, and kept in touch. Soon there was an opening for an Agile Coach at VersionOne, and the rest, as they say, is history. I’ve been an Agile Coach & Product Consultant with VersionOne for about a year and a half now. The access and influence I’m afforded in helping organizations moving the Agile needle is amazing. It’d be hard to find this kind of opportunity with any other company. At the end of the day, I like helping people. And in my current role, it happens to be a perfect fit.
What happened in the mid 1980s? Perviously women were in the hi-tech industries at the same rates as any other industry - but then it all changed. Women fled the compute sciences field. Is this the rise of the computer geek era?
Was it the geeks that ran the women away? Or was it the lack of women that attracted the geeks? Was there cause and effect or just an interesting correlation?
Planet Money has an interesting investigation and some answers - give it a listen.
When Women Stopped Coding :: Planet Money - NPR
I’m 35 and only recently I truly nailed what drives my life — it’s “creation”. When I create something meaningful I feel really great. My creations are not tangible in most cases, like poems, songs, design solutions, new product features, articles, books and blog posts. In general I think creation of anything that lasts is a good way to spend your life.
Deep immersion into a working process turns off everything around. You suddenly ignore all external sounds, you don’t feel how minutes and even hours passing by, you don’t notice poor lighting and reject timid body requests. Then you wake up and check the result. Maybe it’s not perfect, maybe it’s just a start of something significant, maybe you will throw it away in several days after critical examination, but nevertheless you have a sense of achievement. You’ve just completed a thing that may be a part of your legacy.
Can you write? Can you invent a software that changes people lives? Can you build a house? You never know till you try. Your life passion is not “programmed”, it should be “discovered” via experiments and achievements. Moreover, public recognition in many cases is not a good indicator of your achievements. Your personal feelings do matter. When you achieve something and enjoy the process, it is a good signal that your experiment was successful and you should keep going. When you spent quite a lot of time on, let’s say, quantum physics with no clear results and theoretical constructions bored you to death, maybe you should try something else (or maybe you just have a depression, but it’s curable).
Any startup and any ambitious mature company should hire as many creators as it can. These people are enthusiastic, active and relentless. They are the engine of a company. They keep learning, experiment a lot and failures are just a part of their working process. Every team desperately needs at least one creator, otherwise it will be mediocre at best.
How to discover a creator? It is relatively easy to do. Usually they can have something from the list below:
- Side products (frameworks, apps, whatever)
- Blog, articles, books, whatever
- Hobbies related to creation (painting, robots construction, fancywork)
- They usually like LEGO and Minecraft (this option alone is not 100% proof that a person is a creator)
Consumers are all around. We all consume books, movies, TV shows, cars, food, etc. How many of us transform all these consumed information, experiences and skills into something meaningful? Surprisingly, creators are quite rare. It’s incredibly hard to find one and align his goals with company goals. Sometimes they are not polite and hate everything that blocks or slow downs acts of creation. They will not tolerate political games and bureaucracy. Most attempts to cheat them and exploit them will fail in the long run.
We need to build companies that promote honesty, creation and learning. I’m here to create. You?
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Der Deming Cycle begleitet mich als Mensch schon ein Leben lang. Die dahinterliegenden Begriffe sind umgangssprachlich schnell erklärt (Für eine intensivere Auseinandersetzung siehe http://en.wikipedia.org/wiki/PDCA oder die Vielzahl der Bücher zum Thema.)
Plan – Lege fest, wie Du das Ziel erreichen willst.
Do – Zerlege das Ziel in kleine Schritte und führe diese aus.
Check – Analysiere das Ergebnis dieser Schritte.
Act – Führe korrektive Maßnahmen durch und mache diese zum Bestandteil des nächsten Durchlaufs.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Das Konzept ist ein Grundbestandteil der Scrum Methodik und somit ein fester Bestandteil unserer täglichen Arbeit. In den Estimation und Sprint Plannings #1 & #2 planen wir, WAS getan und WIE es getan werden soll (Plan). In den Sprints setzt das Team diese Planung durch die Ausführung von Tasks um (DO). Im Review und in der Retro sehen wir uns an, wie es für die Kunden und für das Team gelaufen ist und was wir in der nächsten Runde besser machen können (Check). Diese konkreten Verbesserungsvorschläge nehmen wir mit in die nächste Runde, um wieder Dinge ein Stück weit zu verbessern (Act).
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Es ist ein ständiger Kreislauf. Als Metapher dazu fällt mir der ständige Kreislauf der Natur ein. Der Frühling ist der Anfang: Es fangen die ersten Triebe zu sprießen an und die Luft ist voll von Hoffnung auf Wachstum und darauf, in diesem Jahr ungeahnte Größen zu erreichen. Im Sommer beginnt der Wettbewerb der Schönsten: alles blüht und zeigt, welche Pracht die Natur entwickeln kann. Im Herbst ist Showtime: Was wurde denn wirklich produziert und wer trägt die meisten Früchte? Der Winter ist die Regenerationsphase: Es gibt eine Ruhepause, in der die Natur ihre Kräfte sammelt, um im Frühling den Zyklus wieder neu beginnen zu können.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
So und nun folgendes Szenario: Mutter Natur sagt eines Tages als Personifikation des gesamten Kreislaufes: “Puh, immer dieser Kreislauf und dieses ständige Verbessern und Verändern der Gene und das Mutieren. Ach lassen wir das doch einfach sein. Wir haben das doch schon so einige Jahrmillionen Jährchen gemacht, langsam sollte ich den Dreh ja raus haben, ich hör jetzt einfach auf mich zu verändern. Ich hab mein Ziel erreicht.”
Klingeln da nur bei mir dir Alarmglocken oder geht das anderen Lesern auch so? Ich habe den starken Verdacht, dass diese Maßnahme kein gutes Ende für die Natur (geschweige denn für uns Menschen) haben würde. Was würde mit unserem Ökosystem passieren, wenn Bäume sich entschließen würden, sich nicht mehr an ihre Umstände anzupassen und sich zu verbiegen, um das Sonnenlicht zu erreichen? Was würde passieren, wenn Blumen nicht immer neue Geruchsstoffe entwickeln würden, um Insekten jedes Jahr aufs Neue anzulocken?
Das ständige, nie aufhörende sich Verändern ist ein stetiger Bestandteil der Natur, dem wir unser Überleben verdanken. Mehr noch, wir Menschen selbst befinden uns in einem ständigen Veränderungsprozess, der unser eigenes Überleben ermöglicht. Eine Lebensphase wechselt die nächste ab. Was gestern noch unglaublich wichtig war, kann morgen schon bedeutungslos sein.
In diesem Sinne, feiern Sie in Scrum den Herbst (Review) und nutzen Sie die Winter (Retrospektive), um sich Gedanken zur Optimierung der nächsten Iteration zu machen – aber bitte vermeiden Sie es, das Ende von Scrum zu suchen. Das Ende von Scrum als iterativer Prozess wäre das Ende der Weiterentwicklung. Die Weiterentwicklung ist jedoch der größte Vorteil auf einem sich verändernden Markt und hilft, jede Schwierigkeit zu meistern.
In this episode of The Weekenders, Tito spends the weekend trying to organize his friends to follow his agenda, with disappointing results. Frustrated, he comes home for dinner…
Tino’s Mom: You know, a kite flies on a string, not a stick.
Tino: [pause] Wow! I could see your lips moving, but it was like you were just going “blah, blah-blah”.
Sometimes, organizational change conversations feel like this.
Do you know about the Conscious Software Development Telesummit? Michael Smith is interviewing more than 20 experts about all aspects of software development, project management, and project portfolio management. He’s releasing the interviews in chunks, so you can listen and not lose work time. Isn’t that smart of him?
If you haven’t signed up yet, do it now. You get access to all of the interviews, recordings, and transcripts for all the speakers. That’s the Conscious Software Development Telesummit. Because you should make conscious decisions about what to do for your software projects.
I can’t shake off the impression that being a manager and guilt somehow goes hand in hand. It seems like managers cannot have a peace of mind for a few minutes, especially in the current online world. A manager is online 24/7, on her laptop, blackberry, smartphone. The work follows her like a shadow (which the online world basically is). But instead of embracing this digital world, managers tend to dislike it. In my opinion, the reason for that is that managers still have the illusion of a traditional work-life-balance. I have noticed that the traditional work-life-balance, in other words, 8 hour work day (Monday to Friday) does not exist.
The manager will always lose with the traditional 5 work day (38 hours/week) mindset. It seems like the manager cannot satisfy anybody, not even herself. Of course you can always work harder and much more, but the fact is not how much you work rather than how effectively you use your time. The reality is that you cannot work on three projects at the same time. You cannot persuade yourself by thinking three hours of sleep every night is fine. These habits will lead to a self-destructing life sooner or later. If you want to be effective as a manager then you have to commit yourself on one task at a time. You are asking why?
Pretty simple: sleep deprived people are not good at rational decision making nor are they awake enough for decoding the gut feeling which helps to make the right decision. (There is a reason why studies found out that a person with 24 hours sleep deprivation drives as a good as someone who is drunk). Hence, people who lack a lot of sleep are basically useless.
So what could be the solution to this problem? You could quit your job and start growing vegetables in your garden or just make a few changes to your lifestyle. For example, I have found these solutions working for me:
- I sleep 8 hours a day (here are 10 reasons why) and that means I am not reachable except when someone is calling my emergency number.
- I stopped doing several things at a time, instead I do only one task at a time – multitasking is a myth, which simply does not work (if you do not believe me look at this interview with Stanford professor Clifford Nass).
- As a Scrum Consultant I have learned to commit myself to the one thing at a time. In other words to my sprint planning and daily tasks, which leads to a focused and better outcome.
My main responsibility as a ScrumMaster is to enhance efficiency, and a burned-out Manager would stop the productivity completely. As a ScrumMaster you have to act as a manager, shrink, developer, doctor, engineer, etc. I call it a 360° versatile role. So this goes out to the managers who understand where I am coming from. Just try this for a month and tell me about your experiences.
- Boris moves on – Embrace change
- Organisations need to understand …
- Estimation, Estimation, Estimation
One of the ironies of being a technologist in the Agile world is that while we love our tools and toys, we also know that some things should be done by hand. One of my jobs as a consultant at VersionOne is to help people understand what the tool will and won’t do. Needless to say, I believe wholeheartedly that the tool does all that it should, and is a fantastic tool for understanding where we are as a team, and where we intend to go. Its a very interesting balancing act, and I have always been impressed, especially when I was a customer, at how well the product management team performs this act.
I am often asked “when will you automate the workflow for a [epic/story/task/test]”? My answer has been the same for quite some time now: “hopefully never”. This gets me some interesting responses, mostly disbelief. The fact that the workflows are not predefined is not a missing feature, but a fundamental understanding of a basic fact. Automated workflows are inherently not Agile.
Let’s start with the most glaring evidence of this statement. The Agile Manifesto’s very first identified value is Individuals and Interactions over Processes and Tools. Tools are valuable when they enable interactions between individuals. When they start to replace those interactions, we are hurting ourselves. Agile is about being able to be quick on our feet and embrace change, even late in development. Having a tool enforce what should happen next slows that down. Let the tool represent what is going on, not try to decide what is going on.
The next challenge is the fact that Agile teams understand the pitfalls of Big Design Up Front. If we acknowledge that trying to create an entire design and architecture up front is a waste of time and energy, why don’t we acknowledge the same for designing a process up front? There are just too many different states that a story, etc. can be in during development to be able to predict the flow. Any attempt to do so is taking energy away from our primary purpose, which is providing value to our customers. Obviously we will have some agreements of general ideas, like Test comes first, and a story isn’t accepted until all of the tests pass, but we don’t need to automate that.
Lastly, let’s remember the main difference between Agile planning ideas and traditional planning ideas. The idea around Agile processes’ planning is to reflect and react to reality. VersionOne provides many ways to do this, my favorite being Team Rooms. I want a wall sized monitor where I can project my Team Room on the wall in my workshop, providing me with a giant informed work-space. Traditional processes try to bend reality to some arbitrarily decided workflow. And guess what? Whenever there is a battle between our planned workflow and reality, reality will always win.