I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says,
Management is Prediction
as a inference from Deming. When I read this quote,
If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming
I infer from Deming that managers must manage ambiguity.
Here’s where Glen and I agree. Well, I think we agree. I hope I am not putting words into Glen’s mouth. I am sure he will correct me if I am.
Managers make decisions based on uncertain data. Some of that data is predictive data.
For example, I suggest that people provide, where necessary, order-of-magnitude estimates of projects and programs. Sometimes you need those estimates. Sometimes you don’t. (Yes, I have worked on programs where we didn’t need to estimate. We needed to execute and show progress.)
Now, here’s where I suspect Glen and I disagree:
- Asking people for detailed estimates at the beginning of a project and expecting those estimates to be true for the entire project. First, the estimates are guesses. Second, software is about learning, If you work in an agile way, you want to incorporate learning and change into the project or program. I have some posts about estimation in this blog queue where I discuss this.
- Using estimation for the project portfolio. I see no point in using estimates instead of value for the project portfolio, especially if you use agile approaches to your projects. If we finish features, we can end the project at any time. We can release it. This makes software different than any other type of project. Why not exploit that difference? Value makes much more sense. You can incorporate cost of delay into value.
- If you use your estimate as a target, you have some predictable outcomes unless you get lucky: you will shortchange the feature by decreasing scope, incur technical debt, or increase the defects. Or all three.
What works for projects is honest status reporting, which traffic lights don’t provide. Demos provide that. Transparency about obstacles provides that. The ability to be honest about how to solve problems and work through issues provides that.
Much has changed since I last worked on a DOD project. I’m delighted to see that Glen writes that many government projects are taking more agile approaches. However, if we always work on innovative, new work, we cannot predict with perfect estimation what it will take at the beginning, or even through the project. We can better our estimates as we proceed.
We can have a process for our work. Regardless of our approach, as long as we don’t do code-and-fix, we do. (In Manage It! Your Guide to Modern, Pragmatic Project Management, I say to choose an approach based on your context, and to choose any lifecycle except for code-and-fix.)
We can refine our estimates, if management needs them. The question is this: why does management need them? For predicting future cost for a customer? Okay, that’s reasonable. Maybe on large programs, you do an estimate every quarter for the next quarter, based on what you completed, as in released, and what’s on the roadmap. You already know what you have done. You know what your challenges were. You can do better estimates. I would even do an EQF for the entire project/program. Nobody has an open spigot of money.
But, in my experience, the agile project or program will end before you expect it to. (See the comments on Capacity Planning and the Project Portfolio.) But, the project will only end early if you evaluate features based on value and if you collaborate with your customer. The customer will say, “I have enough now. I don’t need more.” It might occur before the last expected quarter. It might occur before the last expected half-year.
That’s the real ambiguity that managers need to manage. Our estimates will not be correct. Technical leaders, project managers and product owners need to manage risks and value so the project stays on track. Managers need to ask the question: What if the project or program ends early?
A number of years ago I worked with an EDI (Electronic Data Interchange) team that was troubled with a large level of WIP (Work In Process) and slow movement of work through a system with many external dependencies. Work was regularly blocked waiting for unresponsive peers from the other companies. Work would languish in partially completed states and eventually be abandoned, either because the business relationship changed or the team gave up and turned their attention towards more likely prospects.Looked like great place to apply kanban
These sounded like great problems to solve with the help of the Kanban Method and I was eager to get started. This thinking, however, set us on an educational but somewhat fruitless path. The results weren’t what we expected.Applied the Kanban Method
We mapped out the value stream, modeled it appropriately in a kanban, and used the kanban system for a while to get visibility into the process and gain understanding. That was a success.
The Kanban Method helped us confirm that each analysis, development and QA step in their value stream took little value-added time. Nothing unusual or out of the ordinary was happening in any of the stages. We weren’t worried about vacations or someone getting hit by a bus. There were no bottlenecks.
The kanban helped us discuss Lean concepts and apply them to our situation.Got some benefits but nothing real or substantial – no WIP reduction or lead time reduction
Our initial goal was to visualize the process, reduce WIP, simplify prioritization, and look for improvement in lead-time, especially through reduction in delay. We got the visualization and felt we didn’t need as much as we got. We more fully understood the amount of WIP, but limiting it would not enable any additional swarming. Perhaps we got the simplified prioritization, but that came more from understanding the system and lean principles than from the Kanban Method or the kanban (the board) itself.
We didn’t achieve the lead-time reduction. We couldn’t. The delay was outside of our control.Outside of our control
The root cause was that the team was waiting for external IT shops to complete their part of the equation. It took several rounds of interactions with multiple people outside our company to complete a job. After our team did a little processing, the work item went to sleep in a blocked state and (maybe, someday) would be woken up by the external IT shop if they should decide to respond to our pleading.
Our group would benefit greatly from setting up EDI with their numerous business partners, but the other companies had no incentive to do their part of the connection. (Perhaps you are thinking that we needed to give them a financial incentive. We explored many ideas that just didn’t fit into our sales or business model. Changing the business model was another avenue of exploration but let’s save that for another post.) The times that the external group did respond, it was likely because they had some slack time and/or thought the task was interesting or challenging.It didn’t matter anyway
It really didn’t matter anyway.
Every integration with a 3rd party is of high value to our business — worth the cost of abandonment of work on a large percentage of opportunities. Each successful company pushed through the process is so valuable that it more than covers the costs incurred with those that fail.
Therefore, it was more important to have many “at bats” or “sales calls” than it was to have a short lead-time. Well, maybe ‘important’ isn’t the right word. It’s very important to complete work quickly, but in this case, it’s achievable to have more sales calls. We couldn’t improve our lead-time no matter how important that is.
A better way to look at it is we had extra capacity and used that to push more companies through the process (or, to create demand). We reached equilibrium where a hit suspends additional tries at-bat, and more at-bats ultimately increase hits. Work with an engaged external IT guy competes with making more sales calls. More sales calls yield additional willing external partners.
Yes, that will build up significant WIP over time. Whether we control WIP or not, many of the external companies aren’t going to cooperate and finish the process. We will abandon a lot of work. We try hard to finish whatever we start, but we can’t tell which work will be abandoned before we start.
Ultimately, we considered the cost of being a low priority and deemed it worth it.Lesson learned
Until this experience, I didn’t fully understand the lean principle of Value trumping Flow and Waste Reduction, a lean principle. I was aware of it, but I only thought I understood it. I knew that sometimes we should accept uneven flow if it helps us get value, but I was thinking that would only ever be exception cases. I was thinking that the norm should be to optimize smooth flow. The implication I had missed is that smooth flow isn’t always a general prerequisite for value. Considerable waste and huge WIP and horrible flow might just get you the most value.
(Anyone can get value if you have flow. This kind of environment isn’t for sissies.)
Finally, I began to think about this situation with the EDI team as having options, rather than as a great place to apply the Kanban Method or Lean Principles. I began to see the options in the system trumping the considerable waste, huge WIP and horrible flow.
The moral of the story is that real options thinking, systems thinking and many other such concepts present or yet to come may be more appropriate in some cases than Lean/Kanban thinking. Lean/Kanban thinking is useful, but it isn’t all there is.
Somewhere in the last decade, I had a similar revelation about eXtreme Programming.
With every shiny new hammer, I find more things that look like nails.
So ein ScrumMaster-Job kann gehörig aufwühlend sein. Je nach Projektphase geht es zum Teil hoch her. Widerstand gegen die Veränderung, Unverständnis über das neue Vorgehen, Kollegen, die immer noch einen drauf setzen müssen. Da bleibt die gewünschte Anerkennung von außen oft aus und es fehlt die innere Balance, sie aus dem eigenen Herzen zu holen. Wo kommt sie dann her – die Zuversicht, dass alles gut wird und man auf dem richtigen Weg ist? Wie baut er sich auf, dieser Fels in der Brandung aka ScrumMaster?Hast Du es schon mal mit Meditation versucht?
Es gibt Schulen, die sagen, ein moderner Leader kommt ohne zu innerer Balance verhelfender Meditation nicht mehr aus. Beim Verweilen im gedankenlosen Raum der Leere tauchen sie auf – die unbequemen Sätze vom Chef heute, die ungelösten Probleme aus dem Projekt, die Reue über die harsche Antwort an den Kollegen. Dann sitzen wir da und irgendwann (mit der Übung wird es immer schneller) merken wir, was wir da gerade so denken. Jetzt wird uns bewusst, wo uns etwas aus der Bahn gebracht hat, auch wenn wir es zunächst geschafft hatten, es zur Seite zu schieben.
Es gibt viele Varianten von Meditation. Einige konzentrieren sich in erster Linie auf das Schaffen von Bewusstheit. Sind wir das nächste Mal in einer ähnlichen Situation, merken wir vielleicht schon im selben Moment: “Ach, das ist doch wie beim letzten Mal”. Und wenn uns das ein paar Mal passiert, schaffen wir es vielleicht irgendwann, uns anders zu verhalten. Jeder, der schon einmal eine Fremdsprache gelernt hat, kennt diesen Effekt. Man wird auf einen Fehler hingewiesen und wenn man ihn das nächste Mal macht, wird man unsicher. Irgendwas war hier, doch weiß man noch nicht so recht, welche Variante die richtige ist. Irgendwann weiß man Bescheid, sobald man sich die falsche Variante sagen hört und man kann sich sofort korrigieren. Und zu guter Letzt sagt man es dann gleich beim ersten Mal korrekt.
Was ich damit ausdrücken will: Verhaltensänderungen brauchen Geduld, und Meditation ist ein möglicher erster Schritt auf dem Weg dahin, indem sie uns hilft, uns jene Themen, die uns aus dem Tritt bringen, bewusst zu machen. Als zweiten Schritt braucht es die Entscheidung, es in der Zukunft anders zu machen. Und dann braucht es Geduld und Beharrlichkeit.
Und Meditation kann noch mehr. Neben der Bewusstmachung als Basis für die Veränderung hilft sie uns, gleich jetzt Frieden zu machen mit dem was ist und war. Der Raum ohne Gedanken ist ein guter Ort, um seine Wunden und Schrammen abzulegen. Man kann sie wie ein Paket einfach in die Leere geben. Ohne weiter darüber nachzudenken, taucht man selbst wieder in den gedankenlosen Raum ein. Dort verweilt man so lange, bis der nächste Gedanke auftaucht, der uns so sehr bewegt, dass er es schafft, uns aus der Leere hinaus zurück in unsere Gedankenkreise zu tragen. Und der Kreislauf beginnt von Neuem, bis das Herz Frieden hat und ruhig sitzen kann.
Wenn das Gemüt in gar zu großer Unruhe ist, braucht es eine explizite Bearbeitung der Situation. Hier hilft oft ein Gespräch mit Freunden oder der Familie. Bei beharrlichen Themen empfiehlt sich die Zusammenarbeit mit einem Coach und mit Selbstcoaching-Methoden, wie z.B. einem Tagebuch. Um kurzfristig Dampf abzulassen hat sich ebenfalls Sport sehr bewährt.
Liebe ScrumMaster, was sind Eure Rezepte bei innerer Unruhe, bei mangelndem Gleichmut und verschwundener Gelassenheit, oder gar dem Verlust der Freude und Begeisterung für Eure Arbeit?
- Führung in Scrum | der Manager | Verhalten | Teil 2
- Summer School Weekly Cartoon: Teamführung
- 25. und 26. März | offenes CSM Training in Berlin
Eine Situation unlängst in einem meiner Kundenprojekte: Die aufwändig in mehr als 5 Monaten entwickelte Software-Lösung befindet sich im großen abschließenden Test durch alle Fachbereiche. Es ist ein zeitintensives Verfahren, da viele Stakeholder involviert und jede Menge Testfälle abgearbeitet werden müssen. Ein in der Mitte des Integrationstest gefundenes und zunächst klein aussehendes Problem entwickelt sich während der Analyse zusehends zum „Show-Stopper“. Wichtige Plausibilisierungsprüfungen für den Geschäftsprozess finden wegen einer falschen Logik keine Anwendung. Das To-Do ist schnell klar: Die Methode muss umgeschrieben und verbessert werden, die Anpassungen sind überschaubar.
Was zunächst einfach klingt, gestaltet sich auf den zweiten Blick äußerst problematisch. Die Anpassung muss in einem zentralen Baustein der Geschäftsprozesslogik angepasst werden – das hat große Auswirkungen auf die Geschäftsprozesse. Die Software und Prozesse sind nur sehr mangel- und lückenhaft mit Unit Tests und automatisierten Testskripts abgesichert. Änderungen könnten großflächige Nachtests aller Geschäftsprozesse bedeuten, welche die Produktivsetzung der IT-Lösung um Wochen verzögern wurde. Gute Ideen sind nun gefragt …
Nach einem hektischen und diskussionsreichen Brainstorming hat das Team einen vermeintlich vernünftigen Weg aus der Misere gefunden:
- Die betroffene Methode soll in einem ersten Schritt umfangreich durch zahlreiche Unit Tests an den Schnittstellen abgesichert werden.
- In einem zweiten Schritt wird die Methode überarbeitet und mit Hilfe der Unit Tests auf deren gleiche Funktionsweise getestet.
- In einem dritten Schritt sollen einzelne Testfälle des Integrationstests stichprobenartig wiederholt werden.
Müsste ich eine Analogie für diese Vorgehensweise finden, würde ich die Operation am offenen Herzen wählen. Auch in der Medizin wird versucht, das Herz so gut wie möglich vom Rest der Organe bei gleichzeitiger Beibehaltung seiner Funktion zu isolieren. Beide Vorgehensweisen bergen Risiken, aber sie sind deutlich geringer als bei einem rigorosen Vorgehen ohne vorherige Absicherung bzw. Isolierung.
Wenig überraschend ist, dass die nachträgliche Absicherung der Methode deutlich aufwändiger ist, als wenn sie gleich von Beginn an testautomatisiert aufgebaut worden wäre. Gerade dieses Beispiel hat mir wieder gezeigt, wie wichtig es ist, bestehende Funktionalität gewissenhaft abzusichern, um Änderungen im Code vornehmen zu können. Denn diese Änderungen werden kommen, ganz gleich ob durch Fehler oder neue Anforderungen bedingt.
Respond to change … Start code test-driven!
- Unit Testing: Still Widely Informal / Methods and Tools
- Test Driven Development (TDD) und Scrum | Teil 1
- Certification Test is Postponed
More and more companies realize that focusing on cost savings alone is no longer good enough in today’s fast-paced world. In a competitive landscape where customers have many more options and smaller startups can easily disrupt giants, we need to shift to a value-focused mindset to remain competitive.
Value management in a portfolio context refers to strategic business value (more than the aggregate value of a collection of user stories.) Portfolio-level agility is about optimizing the delivery of that business value.
We introduced the concept of value management in "Portfolio Management for the Fast-Paced World":
“Value management asserts what value is, so we can look at the entire Lean perspective of 'concept to cash' in a value stream. This supports both a more traditional scoring model and benefits realization, as well as approaches like Lean Startup’s Build-Measure-Learn cycle. This pillar represents the portfolio demand -- the demand for development work. “
Value management is a hot topic and we'll be writing about it in the coming months. It’s also an area in which the industry has few experts so engaging with those experts wherever you can is a great way to advance your expertise.
Here's the expertise you should gain if you’re accountable for defining value:
- Adopting methods to detect business opportunities
- Defining market sizing
- Forecasting revenues in new markets
- Understanding existing customer alternatives to get their job done
- Building lightweight business cases
- Picking the “right” things to build from the many possibilities
- Measuring post-delivery value by understanding net lifecycle profits
The problem is that in a fast-paced world, there’s no time to do all those things at a level of detail prescribed in traditional product management curricula. Just as new principles of capacity planning are called for, Value management needs new ways to keep up with the accelerated rate of business. Product management practices must evolve to meet the modern needs of value management.
Agile and Lean practices are popular because they keep pace with the rate of today’s business. Applied to product management, these practices help us retool our product management practices with lighter-weight processes. For instance, minimum viable business cases help us adopt incremental funding methods to redirect funding where more value can be delivered. By the time you write a traditional business case, the opportunity may be gone. Instead, think of applying the continuous cadence planning principle to value management.
In product companies, the product manager role has historically been responsible for defining value as a set of features. In IT, line of business managers and business analysts have been the more common roles, although IT groups could greatly benefit from taking a product lifecycle approach to their work. (Topic for another blog….)
As value receives a bigger focus in organizations looking for greater business agility, various levels and dimensions of value come into play and more roles get involved in value definition. For instance, product manager and product owner are two distinct roles, each having an integral contribution to defining value: product managers define the right features to build, and product owners define how to build the features right. Together they can “Build the Right Thing" and "Build the Thing, Right”. Other roles involved in value definition include business leaders, who track which markets are worth doubling down on; and portfolio managers, who balance longer-term value with shorter-term wins.
The Scaled Agile Framework® (SAFe) has pushed the industry to take a big step forward by making a clear distinction between the product manager role and the product owner role, addressing a pitfall we documented several years ago: when development first adopts Agile practices, there's a propensity to reallocate existing product managers to the product owner role, inadvertently equating the two roles. Merging these two roles causes an organization to lose sight of the evolving business value Agile teams are expected to deliver to their business stakeholders. Prioritization then focuses on what we can do rather than what we should do, and that undermines an organization’s ability to match demand and supply, which maximizes value delivery. Thank you, SAFe, for distinguishing between the two product roles!
However, SAFe and other scaled Agile practices still come up short in guiding organizations on how to define value, and gain the expertise listed above. That’s why we’ve added Building the Right Thing to our Agile University offerings.
The class is taught by expert Linda Merrick from Rally partner Pivotal Product Management. Linda has over 29 years of product management expertise, with a deep understanding of Agile product management. Her class covers the various roles and dimensions of value definition and helps you build the capabilities your organization must acquire to reliably define value, so that development efforts are spent on building the right products and applications. For IT environments, the class also offers practical advice for taking a product approach to IT, a key factor for IT groups delivering business value.
As you enjoy the end of the summer, don’t pass on the opportunity to bring these capabilities into your organization. You may find yourself better equipped to answer the question, “What should we focus on next year?” Our next Building The Right Thing classes take place Sept 9 in gorgeous Boulder, Colorado, and Oct 14 in (not bad either) Raleigh, North Carolina. Take the opportunity to visit our Rally offices during the class breaks!
Wondering how innovation fits into value management? Browse our interactive Enterprise Lean Startup overview.Catherine Connor
It was a normal day. I was reading articles, blogs, emails, Tweets, stories and a host of other types of information. While perusing an item, there was an interesting link and I clicked into another Web location. When I arrived, the newly presented topic was not what I expected so I navigated away from the site. Little did I know, this interaction was most likely recorded by Google Analytics as a “Bounce.”
Google states that, “Analytics helps you analyze visitor traffic and paint a complete picture of your audience and their needs.” Things like Page Views, Average Time on a Page, Entrances and Exits are tracked for behavior. However, the most interesting metric could be the Bounce Rate.
“The Bounce Rate is the percentage of single-page sessions (i.e., sessions in which the person left your site from the entrance page without interacting with the page).” In other words, they were attracted to a specific page and when they arrived, they left the site without interaction. The lower the “Bounce Rate,” the longer they interacted with the page and the site. According to Google, “If you could only choose one metric to look at, Bounce Rate might be your best choice.”
So how does this relate to agile development and agile success? Similar to a Web page or site interaction, a team with a high “Bounce” rate will not be as productive as one that is stable and has stayed together through more than just a short introduction. When people are added or removed on a regular basis, there is not time to understand the full scope of work or the people involved in it.
Medinilla states, “The principle of assigning projects to teams assumes that some team stability is needed. If you are changing team composition every 2 weeks, you are essentially managing a resource pool in disguise. On the other hand, if you are using agile development’s definition of a ‘team, ‘which is more than a group of people commissioned to do the same job, you’ll need some time for the team to ‘glue’ or, as some experts call it, ‘gel together.’” (Medinilla, 2012) It is this unnecessary change, or “Bouncing” that causes confusion, demotivation and poor results in the area of agile success.
There are many benefits to making an agile team stable, one of which is learning. Alistair Cockburn (2006) asserts, “Novices don’t stay novices forever. People who are novices on one project become experienced by the end of the same project… This ability to learn along the way helps many projects. Within a single project’s timeframe, the people learn new technology, new problem domain, new process, and how to work with new colleagues. Often an agile team struggles through the first 2 increments, becoming stronger and stronger until successful results at the end are almost a given.” Bouncing from team to team and project to project doesn’t allow enough time to learn technologies, domain knowledge, processes and characteristics of people.
To help track the Bounce Rate of your agile team, Ekas & Will (2013) have recommended a metric: “Validate that you have a whole team; track the team membership each iteration, beginning with the first iteration; and review it regularly. Confirm that the whole team starts together and finishes together… if the goal is to have stable, dedicated agile teams, then having an indicator immediately available to confirm that this happens can be a big incentive.“
For example: A team of 5 people starts Iteration 1 with a whole team and completes it with the same 5 people so the Team Bounce Rate is 0%. Iteration 2 starts with 5 but ends with 4 so the Team Bounce Rate is 20% and the Team Bounce Rate trend after 2 iterations is 10%. Compare this trend to velocity or throughput after each cycle for evidence of them being connected.
Success with agile development can be measured as a form of bouncing. Both people and process can be affected by it. Just as when a reader will try a certain link and bounce back out before truly understanding the main points of the page, so time is a factor in allowing teams to come together properly.
Give your teams a chance to gel. Give them a chance to learn. Give them a chance to be successful and maybe the bounce rate will turn into a jump for joy.
Cockburn, A. (2006). Agile Software Development: The Cooperative Game. Upper Boston, MA: Pearson Education.
Ekas, L., & Will, S. (2013). Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”. Upper Saddle River, NJ: IBM Press.
Medinilla, A. (2012). Agile Management: Leadership in an Agile Environment. Heidelberg, Germany: Springer Science & Business Media.
Guest post by Johanna Rothman of Rothman Consulting Group
You have some agile teams who are successful. Good for you!
Now you have a strategic project that will require many agile teams to create a program. You know you need people in several locations. You know you need a cross-functional business team to make sure you address the needs of Marketing, Sales, and even Legal. How the heck can you make this happen?
In the agile project management literature, there is a notion of program management. A program is a collection of projects with one business objective. Each project might have its own deliverables. But the real value is in the program. The sum of all the projects is greater than any of the parts.
How do you scale from an agile project to an agile program without a lot of hierarchy?What is the Most Efficient Network in Your Organization Right Now?
When I talk to people about scaling agile, I ask this question:
If you want to move information in your organization fast, what do you?
What is the most efficient way to move information in your organization? People often smile and answer, “The rumor mill.”
People in your company have informal networks. They talk to each other. They help each other. They connect to each other in any number of ways which managers don’t know about. You can use these connections to help agile programs succeed.
“When I discovered that one of the testers needed a little help building an automated test framework, I took 15 minutes and did a screen-share. I showed her how I had started our framework for our testers. It wasn’t exactly what she needed, but it was a start for her.
She understood where I was going. She took that framework, improved on it for her team, and got them going on their own framework. It took me 15 minutes. That’s all. Now, they have their own framework, which is different from ours. That’s okay. Our testers got a show-and-tell the other day from their testers. Our testers came back all excited about the refactoring they could do. I knew it would pay off. – Senior developer
This anecdote is an example of small-world networks and communities of practice in action.
In large organizations, people have mailing lists that are the start of communities of practice. In this example, a senior developer answered a question for a tester. He spent a small amount of time coaching someone in another area of the program. The return was tremendous. “His” testers are now improving on their testing.
In small-world networks, people want to work toward a common goal. Many of them share connections, but it’s not necessary that everyone connect to everyone else. If enough people have connections to many other people, that is good enough.
In large organizations, between the project mailing lists, the functional group mailing lists, the project and program blogs and wikis, and whatever else the agile program uses for communication, there is often a way for people to connect with one another.
The small-world network helps people solve problems rapidly. But that doesn’t help people learn what the status is. How can you organize to learn the status in an agile program and elevate risks? Even if the technical folks can solve their technical problems, you still need a way to organize to see the big picture.How You Organize the Technical Teams in an Agile Program
The software program manager coordinates the delegate project/program managers of the feature teams. As you can see, some of those teams are small programs themselves.
Sally is an agile program manager for six feature teams. Her teams all collaborate on a significant feature set. They work together on a backlog. Once the product owner decides that the team has done enough for that backlog, the feature teams might work on other features. They might exit the program entirely. It all depends on what the program needs. In an agile program, you want to take advantage of your ability to replan based on feature team availability, and backlogs being “done enough.”
Joe, Tim and Henry have single-team projects. In order to show status and elevate risks, Joe, Tim, Henry and Sally would come to the program team meeting, along with the program product owner, the deployment person, and anyone else you need from the technical side of the program.
If you have a program architect, that person would participate, also. Teams embed architects in an agile program. However, you might need to discuss the risks at the program level with an architect. It all depends on your risks and challenges.
A program team meeting is a problem-solving meeting, not a micro-commitment meeting. Since the technical people can solve problems, you don’t need a daily standup for the program team. You do need to elevate risks, and see product backlog burnup charts, among other metrics, to see if the program is on track from the technical perspective.
That’s just for the technical team. What about cross-functional business interests? Cue the Core Team.Agile Program Management Works Across the Business
Back in the ‘80s, I facilitated a cross-functional Core Team across the business. We had a person each from Sales, Legal, Marketing, Training, Finance, Marketing Communications and Hardware. We needed to release within a particular market window so we didn’t miss a specific opportunity. I bet this sounds familiar to many of you. We had inter-dependencies up the wazoo.
I didn’t know about agile. I didn’t know about Kanban. I knew about the value of monthly deliverables, and asking people to commit to small, do-able actions. I knew they each had their “own” work to do. I knew that the program’s work was their work, too. But I suspected they wouldn’t see it that way.
At the beginning of the program, eight months before our projected launch, I asked them to meet biweekly for an hour. We had an action-item list at the bottom of our agenda, which you would recognize now as a Kanban board. Everyone had just one item, and the item only took a few hours to accomplish.
By the six-month mark, we met weekly. By now, we understood how to work together across the organization. The Hardware guy understood how to work with the Marketing guy. (These guys are all generic guys. Some of these “guys” were women guys.) The legal guy was happy because we were not going to ship an empty box. So was I!
Best of all, the product came together, as planned. Not as estimated—not even close. But because we worked our inter-dependencies each week, and replanned as we saw our deliverables, and kept our action items small, we were able to release the product in our market window.
We worked in a cadence, kept our WIP (work in progress) limits small. We replanned. We used what we now know as Lean and agile approaches.Agile Program Management Scales Out, Not Up
Note that the teams don’t try to solve everyone’s problems. The technical teams solve the technical problems. They integrate all the time. They provide good data and insight to the technical program team.
The technical program team solves the risks and understands where the program-level problems are. The program team doesn’t have to solve the technical problems, unless the technical teams are stuck. The technical teams can always ask for help.
Because agile program management uses small-world networks, and is not a hierarchy, this approach scales out well.
The core team solves the cross-business problems. They do not attempt to manage the project portfolio, unless that problem is also in its purview. In small companies, it might also manage the project portfolio.
Program management is not new. Applying agile and Lean methodologies to program management is a new twist on program management.
To read more, see Agile and Lean Program Management: Collaborating Across the Organization, https://leanpub.com/agileprogrammanagement.About Johanna Rothman
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She has been in the software industry for over 35 years—and she never fell for the waterfall promise. She’s the author of eight books about management and project management. Her most recent book is Manage Your Job Search. Her upcoming book is Agile and Lean Program Management: Collaborating Across the Organization. Read more of her writing on www.jrothman.com and www.createadaptablelife.com.
I see Craftsmanship as the answer to an issue that has been rising in importance over the past several years. Agile, as a development methodology, has hit the mainstream. While in many ways this is a good thing, there are some drawbacks. The majority of attendees at the major conferences are now project managers, while in the past they were developers, or at least a fair mix of both. This has helped socialize the ideas around agile development and is a good thing, but we also need to seek balance in the Force. This has given rise to the Software Craftsmanship movement, which is focused on the Art of Writing Software, and what is required to create great software, especially in the agile world. In a previous post, I mentioned how important Craftsmen are to the agile world. But how does one become a Craftsman?
First, lets take a look at the state of affairs of our industry, job-wise. It is pretty well known that being a software
developer is a lucrative career, but the numbers are still somewhat surprising. According to the U.S. Bureau of Labor Statistics, the median salary for software developers in the United States is around $93,000. The statistics further show that the number of jobs in the software development field will grow by 22% in the next 10 years. This is significantly higher than the rest of the job market. So how are we going to fulfill these needs with high-quality developers?
Obviously, we need to train a lot of really talented people. We need them to be able to create software well, and also to be able to work well together. Currently, the primary source of education in software development is via the universities and colleges. Unfortunately, not only is this failing to provide enough programmers for the jobs, it is also failing to provide the high level of quality and experience we will need.
Now, universities are great for a lot of things. They provide a strong level of theory and understanding of the underlying science and logic. What they don’t provide is real-world experience and practical applications of knowledge. This needs to come from somewhere else. My suggestion is to turn the clock back a few hundred years, and turn your team room into a workshop. Let’s populate that workshop with Craftsmen. We may not have all of the Craftsmen we need to begin with, so we need to build and grow them. This can be done by applying an apprenticeship program and using the craftsmen’s model for further career development. Let’s take a look at how this would work.
Let’s begin with the idea of hiring apprentices. An apprentice is someone who may or may not have a formal education in software development. What she will have is the desire to learn. The question remains, “What will she learn and how will she learn it?” For starters, we will focus on five main areas:
- Crafting Code – The art of using one or more programming languages to create clear, well-factored code. We want our apprentices to be polyglots by the time they become journeymen, so we will do this in more than one language.
- Applied Principles – Well-written code isn’t enough. An apprentice needs to understand principles like SOLID, and know how to apply them.
- Technologies and Tools – While programmers need to be able to practice activities like Refactoring by hand, they also need to know how to use certain tools, as well as which tool to choose for a particular task.
- Work Habits – Programming is about more than just showing up, slinging some code, and going home to play Mine-Craft. Especially in an agile software development shop, we need to be able to build muscle memory around the activities that make good programmers great, such as TDD, Continuous Integration, etc.
- Soft Skills – The days of the socially inept programmer are over. Software apprentices will learn how to work in a team, how to communicate with others, and other soft skills that tend to be forgotten in the traditional learning environment.
An apprentice will learn these foundational areas through working on real projects, under the tutelage of a mentor. Ideally, that mentor might be a Master Craftsman, but if one isn’t available, then experienced, well-versed Journeymen will make good mentors as well. At the beginning of her apprenticeship, the apprentice might do some basic things like creating and maintaining the continuous integration environment, some bug fixing, or other tasks. Over time, she will work with her mentor and other Craftsmen on real-world activities and projects, continually adding value to the team. When the apprentice has demonstrated her ability to move on to bigger and more challenging projects and tasks, it’s time for her to be recognized as a Journeyman. We will explore more about the life of a Journeyman in another article. In order to become a Journeyman, the apprentice must show her expertise by doing, not by taking tests. Real work pieces that evidence her abilities in various areas and languages, coupled with having paired with everyone on the team, will determine an apprentice’s ability to move on.
Guest post by Mike Cottmeyer of LeadingAgile
When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.
The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working, tested increment of the product… and is, therefore, what defines the basic requirements for a Scrum team.
When you put analysts, designers, developers, and testers into a single workgroup; let them work across skill-set boundaries, self-organize to balance load; and have them collectively produce a working, tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.
Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness. You have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.
Why Scrum Breaks?
The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real-life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.
When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.
It’s my assertion that these planning dependencies are what result in teams going through the motions of Scrum without realizing value Scrum promises. Last month I did a talk at Agile 2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.
That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.
The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.
SAFe (Scaled Agile Framework) and Value Streams
I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile 2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise-level scale. Scaling Scrum is the topic du jour.
Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean (Leffingwell) has written since he released Scaling Software Agility, I have a ton of respect for his work, and I agree with the basic patterns he has introduced.
(At) this conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.
At LeadingAgile, we typically coach an explicit value stream in the middle-level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.
It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier; it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.
Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.
SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.
We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.
We believe this concept is methodology-independent and will make any methodology you choose better in the long run.
Why SAFe Breaks?
Scrum isn’t trying to break dependencies within the team; it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working, tested increment every couple of weeks.
SAFe isn’t trying to break dependencies within these larger value streams, either. It is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work, and stabilize throughput while producing a working, tested increment every PI.
There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?
If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.
If SAFe is ultimately going to struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about ‘SAFes of SAFes’ or ‘SAFe Product Owner Teams’ or ‘SAFe Portfolio Solutions Teams?’
I suspect we might. I think we might also see evidence of this already.
Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already, given how well SAFe is doing in the market.
If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon, and are people talking about this?
Ken and Jeff Got it Right
Back in 2006 Ken Schwaber put up a slide where he illustrated a team-of-teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely coupled teams (and at that time, that was NOT my reality).
A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that, “teams were never expected to self-organize across class boundaries.” They were implicitly saying that encapsulation was the expectation for a Scrum team to form.
Jeff Sutherland, as we speak over at Scruminc.com is talking about Object Oriented Design (OOD) in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.
I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum nowadays don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.
When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put into place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago, but that is seldom implemented.
I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum.
SAFe is a Compromise
I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.
That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.
At this point in the evolution of my thinking, I find myself in a place where I don’t believe the scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.
We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.
Refactoring Your Enterprise
The only real, long-term sustainable approach to Scaled Enterprise Agile is to take the long, hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.
The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peaceful harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery (DAD), and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.
With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future state starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like which help us get there, while still running our businesses effectively.
If I think about it… that was really what my talk last week was about. It’s up on my blog, and was recorded by the conference, but that might take some time to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend
Guest post by Venkatesh Krishnamurthy, Advisor and Curator, Cutter, Techwell, Zephyr
Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project. I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets. Here are the key ones:
- The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
- Team has neither time pressure nor delivery timelines
I thought to myself that this is not a self-organizing team, but a directionless team.
As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams. I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).
I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.
One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine. As Joseph puts it, building self-organizing teams is like preparing soup. I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.
The below table illustrates the mapping:
- A self-organizing team needs a leader, the right amount of pressure apart from the right set of constraints/goals to succeed.
- The true test of the self-organizing team is their collaboration ability during war time and not during peace time.
- There is a difference between a team organizing themselves and a self-organizing team. Don’t ignore the “self” part.
I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1)
The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2)
Problem #1: They have a very large program, not a series of unrelated projects. They also have projects.
Problem #2: They want to use capacity planning, instead of flowing work through teams.
They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization.
If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole.Don’t Predict the Project Portfolio Based on Capacity
If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it.
First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways.
When you have component teams, not feature teams, their interdependencies are significant and unpredictable. Your ability to predict the future based on past velocity? Zero. Nada. Zilch.
This is legacy thinking from waterfall. Well, you can try to do it this way. But you will be wrong in many dimensions:
- You will make mistakes because of prediction based on estimation. Estimates are guesses. When you have teams using relative estimation, you have problems.
- Your estimates will be off because of the silent interdependencies that arise from component teams. No one can predict these if you have large stories, even if you do awesome program management. The larger the stories, the more your estimates are off. The longer the planning horizon, the more your estimates are off.
- You will miss all the great ideas for your project portfolio that arise from innovation that you can’t predict in advance. As the teams complete features, and as the product owners realize what the teams do, the teams and the product owners will have innovative ideas. You, the management team, want to be able to capitalize on this feedback.
It’s not that estimates are bad. It’s that estimates are off. The more teams you have, the less your estimates are normalized between teams. Your t-shirt sizes are not my Fibonacci numbers, are not that team’s swarming or mobbing. (It doesn’t matter if you have component teams or feature teams for this to be true.)
When you have component teams, you have the additional problem of not knowing how the interdependencies affect your estimates. Your estimates will be off, because no one’s estimates take the interdependencies into account.
You don’t want to normalize estimates among teams. You want to normalize story size. Once you make story size really small, it doesn’t matter what the estimates are.
When you make the story size really small, the product owners are in charge of the team’s capacity and release dates. Why? Because they are in charge of the backlogs and the roadmaps.
The more a program stops trying to estimate at the low level and uses small stories and manages interdependencies at the team level, the more the program has momentum.
The part where you gather all the projects? Do that part. You need to see all the work. Yes. that part works and helps the program see where they are going.Use Value for the Project Portfolio
Okay, so you try to estimate the value of the features, epics, or themes in the roadmap of the project portfolio. Maybe you even use the cost of delay as Jutta and I suggest in Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio (yes, this book is still in progress). How will you know if you are correct?
You don’t. You see the demos the teams provide, and you reassess on a reasonable time basis. What’s reasonable? Not every week or two. Give the teams a chance to make progress. If people are multitasking, not more often than once every two months, or every quarter. They have to get to each project. Hint: stop the multitasking and you get tons more throughput.
Auch in stark regulierten Branchen wie der Medizintechnik ist es möglich, Produkte mit Scrum zu entwickeln – das hat sich mittlerweile von den IT-Abteilungen deutscher Dienstleistungsunternehmen über den innovativen Mittelstand bis in die großen Konzerne durchgesprochen*. Aber wo anfangen, wenn die Entscheidung für Scrum einmal gefällt wurde? Der Erfolg Ihres Projekts steht und fällt mit dem Team.
Scrum, richtig gelebt, bietet Ihnen die Möglichkeit, sämtliches Know-how, das Sie für die Entwicklung Ihres Produkts benötigen, in einem Team zu bündeln. Auf diese Weise lassen sich zusätzliche Aufwände und Redundanzen an Übergabepositionen minimieren und gleichzeitig dringend benötigtes Wissen beinahe automatisch auf mehrere Köpfe verteilen.
Für die Hersteller medizintechnischer Geräte bedeutet das allerdings nicht nur, Anwendungsentwickler und Tester zusammenzusetzen. Zu der ohnehin schon komplexen Aufgabe, Hardware und Software miteinander zu kombinieren, kommt hinzu, dass konstruierte Teile bestellt, Risikomanagement-Checklisten abgearbeitet und vor allem regulatorische Anforderungen erfüllt werden müssen. Neben Hard- und Softwareentwicklern sowie Konstrukteuren brauchen Sie in Ihrem Team also auch noch einen Einkäufer, jemanden aus der Produktdokumentation und eine Person, die sich mit den regulatorischen Anforderungen auskennt.Pilotteams nicht als Wetterfrösche missbrauchen!
Viele Unternehmen treffen die Entscheidung, Scrum zunächst in Pilotprojekten auszuprobieren, um die Organisation nicht zu überfordern und ein Gefühl dafür zu bekommen, ob das funktionieren kann, oder nicht. Der Gedanke, die Organisation nicht zu überrumpeln, ist nachvollziehbar, und das Aufsetzen einer Pilotgruppe auch empfehlenswert.
Aber: Jedes Pilot-Team wird früher oder später an strukturelle Grenzen stoßen, vor allem wenn die Abteilungen, die den Teams zuarbeiten, nicht entsprechend geschult sind. Insbesondere wenn es um Anforderungen „aus dem Feld“ oder seitens der Regulierungsbehörden geht, kann die Integration entsprechender Know-how-Träger in ein Scrum-Team sehr viel Zeit sparen. Heißt das, mein QM – Mitarbeiter ist jetzt 100% der Zeit im Scrum-Team? Nicht unbedingt.Verantwortungsbewusstsein schaffen
Allein das Commitment „entwicklungsfernerer“ Kollegen, regelmäßig zu Meetings wie Sprint Planning, Daily oder Review zu erscheinen, wird einen großen Beitrag zu mehr Effizienz Ihrer Scrum-Teams leisten.
Bei einem unserer Kunden in der Laborautomatisierung gibt es beispielsweise einen Projekteinkäufer, der regelmäßig die Dailies mehrerer Scrum Teams besucht und somit für das Team stets zu verlässlichen Zeitpunkten als Ansprechpartner zur Verfügung steht, sollte es beispielsweise Rückfragen zu Lieferzeiten geben. Und auch für die Arbeit des Projekteinkäufers ergeben sich durch die Unmittelbarkeit viele Vorteile. So bekommt er schnell ein Gefühl für die Dringlichkeit sowie über mögliche Zusammenhänge einzelner Bestellungen.
Auch bei der Erstellung von Bedienungs- oder Servicehandbüchern lassen sich eine Vielzahl von Verzögerungen und doppelten Arbeitsschritten durch die rechtzeitige Einbindung entsprechender Kollegen vermeiden. Schaffen Sie ein Bewusstsein dafür, dass Ihr Projekt nur durch das Zusammenwirken aller Parteien erfolgreich werden kann und das Scrum hierfür den notwendigen Rahmen bietet. Haben Sie die Rahmenbedingungen einmal abgesteckt und kommuniziert, werden sich Ihre Teams so aufstellen, wie sie es für eine anwenderfreundliche und normgerechte Produktentwicklung brauchen.
*Sowohl der Technical Information Report TIR 45:2012 der AAMI (Association for the Advancement of Medical Instrumentation ) als auch die Prozess-Norm IEC 62304 geben Herstellern explizit die Freiheit, ihre Produkte so zu entwickeln, wie sie es für richtig halten – solange die Produktsicherheit und -qualität gewährleistet bleiben.
- Wann ist ein ScrumMaster erfolgreich?
- Auch wenn’s mal wieder länger dauert: Pull die wichtigsten Themen zuerst
Ich werde immer wieder gefragt (meist von meinen Kollegen), wie ich es schaffe, neben meinen Trainings und Consulting-Aufträgen auch noch Bücher zu schreiben und Blogbeiträge zu verfassen. Es ist ganz einfach: Ich schreibe. Ich erzähle euch mal, wie so ein Tag aussehen kann.
Heute – Sonntag – habe ich meine Frau und eine Freundin auf ein Reitturnier begleitet. Wir sind um 06:00 aufgestanden, um 07:00 habe ich unser Pferd Rübe geputzt, dann sind wir eine Stunde gefahren und irgendwann gab es für mich mal eine Pause von 20 Minuten. Ich habe mir einen Kaffee gekauft, mich hingesetzt mein derzeit favorisiertes Schreibprogram Writer, ein Google Chrome Plugin, gestartet und geschrieben.
20 Minuten später kam meine Frau, ihre Freundin brauchte Hilfe mit ihrem Pferd. Also den Rechner zugeklappt, eingepackt und in den nächsten zwei Stunden zugeschaut, wie die beiden sehr erfolgreich waren. Dann gab es wieder 10 Minuten: Den Rechner rausgeholt unter den Baum gesetzt und da weitergeschrieben, wo ich aufgehört hatte. Klar muss ich dann immer den vorherigen Absatz umschreiben um reinzukommen, aber ich konnte wieder einige hundert Worte schreiben. Meine Frau kommt vorbei und bittet mich, das Pferd zu halten. Ich klappe den Rechner wieder zu. Dann waren wir fertig, haben die Pferde in den Stall zurückgebracht, die beiden anderen Pferde versorgt und sind nach Hause gefahren. Dort geduscht, etwas gegessen und meine Frau ist noch einmal zu den Pferden gefahren (das ist heute eine Ausnahme) und ich sitze seit 75 Minuten hier am Küchentisch und schreibe.
Zugegeben, ein solcher Tag ist auch für mich eine Ausnahme. Ich bin gerade wieder vom Schreiben gefangen. Sonst würde ich nicht in den “Auszeiten” schreiben. In den letzten 8 Wochen, nachdem ich das Manuskript zu “Selbstorganisation braucht Führung” an Dolores, meine Editorin, abgegeben habe, war ich erst einmal fertig mit Schreiben. Ausgeschrieben. Doch die letzten Blogs, von denen ihr in den letzten Tagen wieder einige lesen konntet, zeigen, dass es so viel zu bemerken gibt, das muss einfach zu Papier bzw. zu Datei gebracht werden. Normalerweise schreibe ich morgens, kurz nach dem Aufstehen, oder abends im Hotel, am Flughafen, wenn ich auf den Flieger warte, im Zug nach irgendwohin.
“Aber wie macht er das?”, höre ich fragen. Einem guten Freund von mir passiert das Gleiche beim Fotografieren. Er macht Fotos. Ständig. Ein anderer malt. Ich schreibe – ich denke dabei nicht nach, sondern ich schreibe. Manchmal wird es gut, manchmal sehr gut. Brauchbar ist es mittlerweile immer – aber das ist Übung. Macht es Spaß? Ohne Ende.
Versucht es auch, ich kann es nur empfehlen. Hört einfach auf darüber nachzudenken, was ihr schreiben wollt und schreibt.
- Führung ist?
- Über das Schreiben: Leidenschaft | Passion | Freewriting
- Bin ich am Arbeitsplatz zufrieden?
We’re excited to announce Axosoft’s Version 14.3 Release! Here is what you can expect in the newest version:
Teams: Make team management a breeze by organizing your users by teams and sub-teams.
SMS settings: Let Axosoft send you text notifications on your mobile devices.
UX boost: Drag and drop images into text fields, copy and paste images into large text fields, see user gravatars in card view and more.
This is a big one. Many of our customers (that’s you!) need the ability to group users together in the system to manage their progress more easily, gain better visibility, and include the whole team. Hence the introduction of team management.
You can now assign items to teams, filter by teams, send notifications to teams and more. Teams are located under the Users and Teams section of the Organize panel. This is where you group your main team and create smaller teams within a larger grouping of users as well.
In short, anywhere you could assign an individual user to something, you can now assign a team. Plus if the team ever changes it’s easy to update the roster for the next cycle.
Ah texting. For those of you who love your mobile devices, we now give you the ability get text notifications from Axosoft (US and Canada only). Go to Tools/ System Options/ SMS settings to enable SMS settings. For hosted customers, that’s all you need to do. If you’re an installed customer, you will need to create a Twilio account to configure the SMS feature in your network.
Once enabled, go to Tools/ Notifications/ Manage to edit a notification template and enter a phone number in the recipients box. You will then get a text from Axosoft anytime an item is created, changed, or deleted.
This functionality will be free while in Beta.
It’s the little things that count. That’s why we’ve updated several smaller features to boost your everyday use of the Axosoft Suite. We’ve introduced Global Dashboard Settings to allow quick changes to your whole dashboard. For example, by clicking the gear by the huge plus sign in your dashboard, you can now update the release or sprint for a particular dashboard once you’re ready to start the next cycle.
Here’s a quick list of other new functionality you can try with this release:
Copy and Paste into large text fields (drag and drop images too, yay!)
Right click to add a worklog
ID and title always in view when scrolling in edit mode
Gravatars now included in card view
Plus join us for our API Webinar on September 3rd to learn about the latest version of our API. That wraps up what’s new in 14.3. Stay tuned for more awesomeness!
First, I would like to credit Eric Ries in his 2010 Web 2.0 speech for giving me the idea for these awesome graphics. If you have never seen the speech then I highly recommend the version found on YouTube. I have always admired people with creative slides who can capture ideas with elegant simplicity. Since my artistic ability peaked in the first grade, the images in this post demonstrate my foray into abstract expressionism and hopefully convey the point of why we in software need iterative planning.Unknown Problem | Unknown Solution
Most software changes start life in the state of an unknown problem with an unknown solution. Now the product mangers reading this may beg to differ but, most of the time a vague idea on having the software do something is not a known problem space. Say for instance I want to allow uninsured people to buy insurance as a government subsidized rate. Most of us can imagine that this is a huge problem space and truly we would have no idea how to make this happen. In this case the problem space and the solution space is unknown. In order to plan a software delivery that will solve the want above, I need to clearly understand the problem that needs to be solved. To do this in agile software delivery we create something called a roadmap. The roadmap is a way of breaking this big unknown problem into smaller chucks that we can estimate (“guess wrong”) as to how long it will take to implement them. It is usually at this stage that these chunks of work are funded.Known Problem | Unknown Solution
Now a software release is ready to be planned with some chunk of the roadmap. In order to do that, the problem should be fairly well known and can be broken it into pieces. These pieces can be estimated (“guessed wrong”) and slotted into delivery iterations. Lets say we want to allow people to log into a website and sign up for insurance. This is a relatively well-known problem space, there are security concerns, 3rd party integrations, databases, platforms and deployments. Maybe this will not all fit in one release, but with more elaboration and planning a reasonable release plan with a list of risks will emerge. It is usually at this stage that the guess of the size of the thing in the roadmap is known to be wrong and changes must be made to the roadmap.Known Problem | Known Solution
Finally we are ready to plan an iteration. So take a chunk of the release plan and break it into pieces and as a team there needs to be some certainty that these pieces of work can be completed in the sprint. If there are still things that don’t have a clear solution then don’t take those in the sprint and take a spike or research item instead. It is now that the wrongness of the guess during release planning is known and adjustments can be made both to the release plan and the roadmap.
Planning and elaboration go hand in hand as items move from unknown problem -unknown solution to known problem-unknown solution to known problem – known solution.
Als ScrumMaster bzw. Agile Consultant stelle ich am Anfang von jedem Scrum Meeting immer dieselbe offene Frage in die Runde der Teilnehmer: „Weshalb ist dieses Meeting Teil des Scrum Flows?“ Wohlgemerkt: Das frage ich nicht nur, wenn ich ein Team gerade neu übernommen habe, oder wenn wir einen Termin neu gestalten. Für mich hat diese Frage einen positiven Aspekt, den man immer wieder wiederholen darf – jenen des kontinuierlichen Lernens und der Frage nach dem Sinn.
Eines habe ich nämlich durch Scrum gelernt: Es hat alles einen Sinn. Und wenn etwas tatsächlich doch keinen Sinn hat, dann ist es Waste und sollte tunlichst geändert bzw. abgeschafft werden! Da wir als Firma Boris Gloger Consulting immer öfter von Managern angerufen werden, um Scrum in ihren Unternehmen zu implementieren, hat der Begriff „Scrum“ bei vielen Mitarbeitern auch das Synonym „neuester Trend“. Gerade dienstältere Mitarbeiter belächeln mich dann manchmal und meinen nur „Sie wissen ja gar nicht, wie viele Prozesse wir hier schon kommen und gehen gesehen haben. Dieses Scrum wird der nächste gewesen sein“. Dagegen weigere ich mich jedoch. Ja, es ist aktuell trendy, agil zu arbeiten (siehe „Studie Agile Status Quo“). Doch gibt es auch einen guten Grund dafür!
Damit Scrum nicht nur als Trend wahrgenommen und gelebt wird, ist es wichtig, dass jene Menschen, die
damit arbeiten sollen, den Sinn dahinter erkennen. Und aus diesem Grund stelle ich die Frage nach dem „Warum“ am Anfang jedes (Scrum-)Meetings. Auch vor kurzem wieder am Anfang der Sprint Retrospektive bei einem cross-funktionalen Team, das schon seit einem Jahr Scrum in der Hardware macht. Kleiner Tipp am Rande: Hört gut zu. Die erste Antwort beantwortet meistens das Was. Auch dieses Mal kam wieder die Antwort: „Wir schauen uns an, was im letzten Sprint gut gelaufen ist und was wir im nächsten Sprint anders machen wollen“. Ja – das ist korrekt. Doch beantwortet das meine Frage nach dem Warum? Nein. Also noch einmal fragen: „Weshalb sitzen wir jetzt in diesem Meeting?“
Ein schöner Nebeneffekt dieser offenen Frage ist, dass es Zynismus und lustige Kommentare zulässt. So kann man gleich mit einem Lachen in ein Meeting starten. Oder Bedenken aus dem Weg räumen. Falsche Interpretationen gerade ziehen. Einen Einblick in die Stimmung im Team bekommen. Und auch als Agile Consultant immer wieder Neues erfahren.
Versucht es selbst! Ich freue mich über Erfahrungsberichte.
- Die Retrospektive macht das Team, das Team macht die Retrospektive
- Scrum – wider die Methodenfixierung
- Klassiker | Sprint Planning