[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Agile Teams organisieren ihre Prozesse, Strukturen und ihre Performance über ein hohes Maß an Kommunikation. Kurz gesagt, Selbstorganisation ist gleich Kommunikation. Für die Führung agiler Teams, ob disziplinarisch oder lateral, gehört das Initiieren und Gestalten von funktionalem, aber auch sozialem Austausch zu den zentralen Aufgaben. Die verschiedenen “Spielfelder”, die für die interne Teamkommunikation relevant sind, müssen im Auge behalten und bei Bedarf aktiv entwickelt und gesteuert werden.
Teamkommunikation findet grundsätzlich auf zwei Ebenen statt. Zum einen auf der sachlich-fachlichen und zum anderen auf der emotional-sozialen Ebene. Beide können natürlich nicht wirklich unabhängig voneinander betrachtet werden, sie wirken in der Praxis permanent aufeinander ein. Es zeigt sich jedoch in den Teamprozessen, dass im Alltag situativ unterschiedliche Schwerpunkte zu erkennen sind und die vier Spielfelder durchaus unterschiedlich gut funktionieren können. Folgendes Modell kann für Teamentwickler und Führung eine Folie zur Analyse und Intervention bezogen auf die komplexe Teamkommunikation sein.
Im Mittelpunkt von selbstorganisierter Teamarbeit steht naturgemäß das Feld Fachinformation und Austausch - im Sinne von fachlichen und organisatorischen Absprachen, gegenseitigem Lernen. Kommunikation in diesem Feld entscheidet wesentlich über die Performance des Teams. Probleme können dann entstehen, wenn es im Team Wissensmonopole gibt, wenn nicht genügend Zeit für den Austausch zur Verfügung steht oder sich genommen wird, unklare Botschaften gesendet werden, z.B. zu viel E-Mail statt direkter Austausch, etc.
Entwicklungsfragen zu diesem Feld sind u.a.:
- Wie wird mit Bring- und Holschuld von wichtigen Infos umgegangen?
- Wie sind die fachlichen Informationen im Team verteilt?
- Ist der Informationsfluss geregelt und gut strukturiert (z.B. Daily Scrum)?
- Wie sind die Zugänge zu sachlichen Informationen für jeden?
- Wie funktioniert fachliche Kommunikation horizontal und vertikal?
- Wird genügend kommuniziert damit alle voneinander lernen können?
Das Feld Auseinandersetzung ist gekennzeichnet von hoher, z.T. unkontrollierter,
Emotionalität. Es steht in der Regel für ungelöste, eskalierende Konflikte und deren
Dominanz über die sachliche Kommunikation. Die eigentliche Arbeit wird partiell aus den
Augen verloren, es droht Schwächung der Leistung. Es kommt zu Koalitionen, die intensiv
miteinander kommunizieren und sozialem und kommunikativem Ausschluss von
einzelnen oder Teilgruppen usw. Es kann aber auch sein, dass Auseinandersetzungen
zu stark vermieden werden, Harmonie über alles gestellt wird. Das bedeutet oft
Stagnation und Mittelmaß, bzw. die Gefahr unvermittelter Eskalationen.
Entwicklungsfragen zu diesem Feld sind u.a.:
- Wie aggressiv, wie eskaliert ist die emotionale Kommunikation untereinander?
- Wer kommuniziert wie, mit wem und worüber ?
- Wie stark ist die Leistung des Teams betroffen, eingeschränkt?
- Welche Interessen stehen gegeneinander?
- Wie hoch ist die Gesprächsbereitschaft untereinander noch?
- Welchen Anteil an der Kommunikationen haben die persönlichen Befindlichkeiten?
- Wird nur angegriffen oder werden auch gemeinsame Lösungen gesucht?
- Braucht das Team evtl. Unterstützung zur Konfliktklärung?
- Hat das Team zu wenig Mut, bzw. Kompetenzen zu Konfliktbewältigung?
- Müssen Auseinandersetzungen auch mal bewusst provoziert werden?
Das Feld Small Talk definiert die entspannte, beziehungsorientierte Kommunikation im Team. Hier wird über Privates und Alltägliches gesprochen und soziales Miteinander gepflegt. Small Talk ist wichtig für den Abbau von Stress und das persönliche Kennenlernen auf einer nicht leistungsbezogenen Ebene. Und ein oft unterschätztes Element von Teamgeist und Wir- Gefühl. Probleme können hier eigentlich kaum auftreten, höchstens wenn zu viel oder zu wenig Small Talk läuft.
Entwicklungsfragen zu diesem Feld sind u.a.:
- Ist genügend Zeit für diese Art der Kommunikation?
- Wird in den Pausen nur über die Arbeit gesprochen?
- Fördere oder behindere ich als Führung Small Talk?
- Gibt unsere Unternehmenskultur dafür Räume, dürfen wir das?
- Sind möglichst alle eingebunden, wenn nein, wer nicht und warum?
- Gibt es auch außerhalb des Unternehmens Räume für das Zwischenmenschliche?
- Feiern wir uns und unsere Erfolge angemessen?
Spannend ist das Feld des Dialogs. Hier kommuniziert das Team im kooperativen Dialog und bearbeitet gemeinsam vor allem komplexe fachliche Probleme und innovative Themen. Dieses Spielfeld heißt, in unterschiedlichen Meeting- und Workshop-Formaten zu kommunizieren und sich mit positiver Emotionalität, Engagement für das Ganze und hoher Fachkompetenz einzubringen. Dialog heißt Austausch auf höchstem Niveau und immer mit dem Fokus auf der Sache. Probleme können hier mangelnde Dialogbereitschaft, “Kopfmonopole”, schlampige Meetings, fehlende Methoden, zu wenig Beteiligung u.a. sein.
Entwicklungsfragen zu diesem Feld sind u.a.:
- Sind alle im Team dialogfähig und -willig?
- Wie leben wir tatsächlich unsere Meetingkultur?
- Sind Meetingregeln und Strukturen vorhanden und effektiv umgesetzt?
- Haben wir wirkungsvolle Methoden und Techniken?
- Sind alle oder zumindest die meisten mit Engagement und Herzblut dabei?
- Haben wir Spaß und Freude an gemeinsamer, kreativer Problemlösung?
- Wie treffen wir im Team Entscheidungen? Sind wir darin effektiv?
- Werden Ergebnisse und Maßnahmen committet und nachhaltig umgesetzt?
- Kümmern wie uns um angemessene Kontrolle?
Diese vier Felder kennzeichnen die komplexe und anspruchsvolle Vielfalt der Kommunikationsprozesse in selbstorganisierten Teams. Weit mehr als in konventioneller Teamarbeit sind alle im Team aufgefordert, diese vier Felder optimal mitzugestalten und zu entwickeln. Führung als funktionales Mitglied des Teams sollte sich hier schwerpunktmäßig als Moderator, Impulsgeber und konstruktiv-kritischer Beobachter verstehen und sich entsprechend einbringen. Das heißt, Feedback geben, ggf. Trainer sein, Rahmenbedingungen schaffen, Impediments aus dem Weg räumen.
Wie im Fußballspiel: Auf dem Platz spielt dasTeam, in der Kabine agiert der Coach.
Wie geht das – die Kommunikation im Team fördern und gestalten? Antworten darauf gibt es im Training “Team Booster” mit Dieter Rösner – alle Infos hier
- Scrum mit verteilten Teams | Jeff Sutherlands Paper and Talk
- 5 min on Scrum | Small Project(s) (-teams)
- Die wertvolle Meetingzeit sinnvoll nutzen, effektiv kommunizieren (Teil 1)
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
What decisions must be made to implement an IT Outsourcing program? Are these decisions similar to the decisions that leaders must make for an Agile program? How do they differ, how are they similar? What are the expected outcomes, and the possible outcomes? Which decisions have high stakes with no-return points along the transition map? Which decisions are safe-to-fail and possible to repeat and iterate toward success?
Comparing and contrasting basic road maps for the implementation of major process change is fraught with generalizations that may easily be questioned. The intent of this paper is to objectively represent the set of high level decisions and expected outcomes that lead to a success regardless of which path is chosen. Choosing the path is your decision.
A general model
If we model the decision path as a journey with an expected destination, but unknown terrain this metaphor may serve us well. Journeys are made of many decision, some made before the terrain is known, some made with little information, many decision must be adjusted as the journey progresses.
…. to do…
Decisions to be made along the path:
Can innovation be separated from execution without extreme risk?Does outsourcing add value -or- just decrease cost?How does the outsourcing approach transition to a value-add mind-set?What need are we addressing with an outsource model: from innovation <-> maintenance?What does an optimized cost reduction model look like? a headless remote team; recruiting agency; software R&D provider; other?What is the right service model for our organization? outstaffing; <-> custom app devHow does one mitigate the risk of vendor lock-in to the outsourcing provider?What does the *right time* to outsource look like?Where is the point of no-return in the decision path?What does outsourcing require that IT is already great at delivering?What does outsourcing require that IT is poor at delivering? Can this capability be outsourced?
Along the journey - where is the point of no-return?
Investigation of Options
“Intelligence should be viewed as a physical process that tries to maximize future freedom of action and avoid constraints in its own future.” — Alex Wissner
A model of intelligence at an abstract level is an organism that preserves options until a specific time horizon at which point it decides while seeking a goal (TED Talk: Alex Wissner-Gross: A new equation for intelligence).
What is the goal of the Information Technology organization?
Is it to reduce the cost of IT to the organizations - or - might it be a more aspirational goal? More in alignment with the corporate mission.
Why do organization outsource?
Software development is not a simple endeavor. Standish Group has studied the problem space for years and release yearly reports that in general show an marginal improvement in recent years from a low point of roughly 80% failure rates a decade ago. However; “[o]utsourcing has not proven to be a magic wand; it has failed to deliver the expected results over fifty percent of the time.” (1, 3) Gartner predicts that spending on outsourcing will increase from $268 billion in 2009 to $325 billion in 2013. Research suggests the reason for this increase is the perception of economic, technological and strategic benefits. These benefits come with additional challenges, and externalities.
Organization outsource to:
- Focus on core activities
- Reduce cost of development executation
- Add staffing flexibility for special projects
- Augment skills not presently available
- Reduce development time associated with project ramp up
- Improve quality (by working with more experienced developers)
- Improve management (by levering vendor’s experience/knowledge)
Define our reason to outsource - be absolutely clear about why. A clear purpose will enable decisions with reasonable chance of success.
What challenges does outsourcing resolve?
The cost model is typically the first response to the reasoning behind the decision to outsource. Engineers in offshore locations are on relatively low compensation plans compared to the US, this relative cost advantage is apt to shrink fast however (5).The scheduling of project manpower and resources is another key reason to outsource. When project ramp up and termination are time sensitive offshoring may have tactical advantages to staffing internal projects with varying resourcing needs.
Specialized skill sets are another key reason to outsource. Assuming that the skill set is not a core capability to the problem domain.
Mid-term budgeting and cost accounting become easier. Small projects cost accounting becomes cost prohibitive so effort must be done to aggregate small project, or define a class of service that allows for ad-hoc scope management.
What challenges does outsourcing compound?
While software product development is a known challenge, outsourcing is a known challenge compounded by more players on the field. The software development process will be distributed across multiple organizations with multiple cultures and value systems.
Outsourcing firms must effectively manage:
- the scope of projects
- the process that implements the deliverables, and
- the people involved (customers, their clients, their staff, as well as vendors).
- Requires constant highly skilled management and logistics
- Increases departmental frustration
- timezone differences lessen communication windows
- need for higher quality architecture
- lower quality of solution (not what we wanted syndrome)
- need for better testing
- scapegoating the vendor
- testing is more difficult & results in longer test/fix cycles
- company morale may suffer
There is no one right model to handle all of these management tasks. In the grand scheme of things, success in outsourcing depends on how well you plan, organize, execute and control these very areas that are required for in-house development also. Failing to understand these factors and relationships puts the outsourcing program in high risk of failure.
Successful Project Scoping for Outsourcing
Projects that are well defined in terms of scope/features (well known technology and well know requirements) are simple and prime candidates for outsourcing [the simple domain of the Stacey Diagram].
Project types require various amounts of effort in scoping - not all projects are the same - don’t treat them similar. The most difficult is the innovative new application platform with a high degree of market risk. These are typically high and to the right on the Stacey diagram. Requirements are not well known, and the technology used is far from certain.
Scope management is the ultimate driver of value delivery. In the traditional PMI Iron triangle managing budget is a well known problem domain, managing schedule is difficult but practical when using a Project Process Management model, however scope management is the most difficult. It is also the leg of the iron triangle that is most often ignored as a lever to be used by the customer to make scope decisions with economic trade-off in mind. Having a value-based model of project success has proven more satisfying to customers than a cost model (implied all scope & implied on schedule) model.
When project scoping is easy and well done the project is ripe for outsourcing.
If scope change management is a likely difficult internal process - then adding a few more contractually obligated layers (vendors) is exasperating the issue. Scope changes must be controlled, they increase workload, and management overhead, they raise costs and lengthen schedules, as well as hamper quality and integration capabilities.
When outsourcing software development perhaps the worst situation is scope creep caused by ineffective change control. This will cause: cost escalation, quality shirking, schedule delays, unused/unnecessary features, reworkitis, staff demotivation. The motivation issue creates a viscous feedback loop enhancing the negative aspects of the other effects.
A latent problem with outsourcing is the division of total project delivery scope. Few new application development project scope out the actual delivery of the product and all it’s ancillary systems and work streams. Scope division is the process of understanding the responsibility and ownership of work to be done in-house and by vendors. Not all of the work may be outsourced. Retaining the knowledge of systems and integrations is key to continuity of the business. Counter these risk via well designed architecture components that are independent of each other. Foster accountability and ownership of components by a single entity. Deploy frequently and test all interfaces.
Outsourcing may provide many economic benefits, yet it still follows basic economic rules. It saves on wages and real estate costs, but cannot always significantly reduce the amount of time that a project takes.
Successful Project Process Management for Outsourcing
The business process of outsourcing is very important and must complement the software development methodology. This management process includes: defining the vendor team structure and interfaces, the development methodology to be executed across the client/vendor system for the project, software development management tools (source control, build systems, test systems, project progress reporting, collaboration & communication tools), proper quality assurance expectations both at the vendor and the client, as well as customer QA.
Team Structure - beyond the typical player on a software development team, outsourcing project typical require the overhead of two key roles. An in-house product manager responsible for daily interactions with the development team insuring timely resolution of problems that arise in the development requirements. A vendor-located technical leader, responsible for the vendor team and highly collaborative with the product manager.
Tools and metrics for monitoring the project should be selected to match the type of project (new development or maintenance), the development methodology (waterfall / agile / lean), and the companies cultures. When selecting a vendor a fluent demonstration of their management tools is a great indicator.
Vendors with a mature outsourcing program will have a well known and easily demonstrated quality assurance process. If the QA work is to be done in-house rather than by the vendor this scope division should be well understood and the cost/benefits weight and measured throughout the life of the project. Establish typical engineering standards such as: coding style guides, documentation standards, controlling procedures, bug tracking and reporting, defect prioritization and triage responsibilities, testing phases in the release plan as durations, release criteria with regard to defect count, severity, types of testing to be performed (usability, regression, performance, load, etc.). One perspective of outsourcing vendors is to gauge their maturity in QA; vendors with a long history and successful future will have developed mature QA capabilities.
A core capability of outsourcing vendors is their communication techniques. When the team is physically separated (as in most outsourcing situations) communication becomes a multifaceted issue with compounding issues such as: language and culture, approval chain of command, time zone, domain knowledge, travel, and industry experience.
Successful Project Stakeholder Collaboration for Outsourcing
Make specific plans to involve the customer, end users, and key stakeholders in the development project. Active participation in the process leads to greater product satisfaction. Clearly define their role and responsibility, setting expectation and constraints on their involvement. The proper balance will change with project type and methodology.
Prior to outsourcing software development the organization must be prepared. This decision has long term effects and will effect the attitudes and motivation of many existing employees. While pursing an in-house development organization hiring decision are biased toward development skills; in an outsourcing organization the managerial skills will ultimately lead to success.
Hiring Mean Development Skills - - > Hiring Organizational SuperpowersSubject Matter Experts - - > CommunicatorsDomain Knowledge - - > Integration / OperationsImplementors - - > Planners
Successful Program Management for Outsourcing
Beyond the typical software development project related management issues, the outsourcing program has higher level concerns to deal with. These are typically handled via contracting and source selection processes, and then via executive level negotiation of problems and breeches.
Typical Outsourcing Issues (non-software development related): (6)
- Liability Insurance
- Software Licenses for third party access to systems
- Ownership of information (sample data and testing data)
- Inter-organizatioal system performance and access requirements
- Service Level Agreements
- Reporting and review of SLA
- System access and security
- Intellectual property indemnity
- Distaster recovery
Many organizations spend countless time and energy selecting and reselecting an outsourcing vendor. This trial and error process may result in a well integrated vendor that is an indispensable partner.
1) A Practical Guide to Outsourcing Your Software Development PDF by Selleo (a Poland based outsourcing firm)
2) Tips for Outsourcing Software Development: Ensure Outsourcing Success HTML by Auriga (a Russian outsourcing firm)
3) Fabriek M, et al; “Reasons for Success and Failure in Offshore Software Development Projects.” [in] The 16th European Conference on Information Systems; Galway; Ireland; 2008
4) Outsourcing Software Development Offshore Pros and Cons by Mark Davies
5) The End of Indias Offshore Dominance by Mark Hebert
6) Outsourcing Issues by e-Zest
7) Outsourcing decision support: a survey of benefits, risks, and decision factors, by Tibor Kremic; Supply Chain Management: An International Journal
8) The Evaluation of the Outsourcing of Information Systems: A Survey of Large Enterprises by Chin-Chia Hsu, International Journal of Management Vol 23, No. 4 Dec 2006
Hacks for your organisation
Hack gratitude with Jean Russel : Gratitude is a key ingredient of Thriving organisation. Gratitude is maybe more difficult to receive, and people are better when they think what they are grateful for , to whom and say it. Jean proposes to make acts of gratitude vandalism , by putting gratitude notes all over the place. And create a gratitude tree to be displayed. Jean is the author of "Thrivability".
Self-organise like life with Michelle Halliday : Life is self-organised around a purpose that is self-preservation. Life is a complex system that has a top priority goal : resilience . Organisations are like living systems , they are complex and self-organised by design. Through a purpose in a middle of a group, is starts self-organising. Any command and control management junkies just can't help it. Any organisation is self organised to respond to regulations and policies.
Freedom is the the N°1 value that make people safe with Jim McCarthy . Jim, author of the Core Protocols a reference for self-organised responsible organisation, reminds us the core of true engagement : recognition of each individual freewill in everyday actions. I used to say that even if freedom is "dangerous" ( by design, no one holds you under a protection shield when you're free ) , it is priceless. The "safety" dimension Jim brings, outlines there is nothing that make us feel safer that facing the danger to act on our freewill.
Organisation comes in circles , with John Buck. Every organisation starts by forming circles , and the most stable form of evolution is to circle forward ( a nice name for a string like form ) . And"Circle Forward" will be the new-new operating system of organisations and maybe the new name of sociocracy ! John revealed also the enormous potential of "nothing". You can do anything starting from nothing , just think at the degree of freedom it gives !
Only fractal structures are scalable , with Doug Kirkpatrick. Morning Star is one of the biggest complains that make tomato sauce ( yummy!). Tomato sauce is a complex matter because it depends of mother nature and complex food industry, yet Morning Star has no hierarchy. It's the No Boss, No Budget constraints, no promotions company, that has a "CLOU" ( read it Clue ) how to provide 40% of the tomato paste for the US food industry. The secret ? Values and culture are part of the company's DNA. And DNA is fractal , it can scale. Culture is fractal. Bingo !
Robert , at the dance party City Hall Cambridge, MA
Have fun and hack culture , with Robert Richman. Have candor , be respectful be amazed and play ! That's how Robert hacks culture. I learned to build amazing soft-ball for energising activities. And the point is not only to play soft ball with a team following whatever rules the group settles, but truly crafting those balls. Amazing ans simple way to get engaged ! Robert is the author of "Culture Blueprint".
The Tip on Open Spaces I participated in many Open Spaces, still Dan ( Mezick) brings some extra surprise in them. The way he energise people to make the results last. From hims and the team committed to do proceedings of the different sessions, I truly learned a new tip : make it last, create the right environment to proceed ... proceedings. And of course , many thanks to Deb Hartmann Preuss as a thoughtful Open Space facilitator. Open Space is a container. Deb owns the art to make it a good fertilising, inspiring container .
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Theodore Levitt may have developed the whole product model to help companies compete more effectively with their products. We wrote about the whole product game based on Mr. Levitt’s work. Recently, I’ve been using a variant of this model as a way to view a product and upcoming roadmap items. It is a powerful way to share a perspective on your product with the rest of the team, and frame conversations about where best to invest.Whole Product Model
As a quick review, Mr. Levitt defined the following model:
Which works in that the center of the bullseye is the heart of the product, and as it grows, it reaches the potential of an imagined marvelous product. It also follows that your product would be hollow if you only focused on the outer rings and not the center.
I’ve found, over the last year or so of messing with the model, that I prefer to think of it as layers building upon one another.
Minor Term Revision
When introducing this way of framing a market space to a team, I have found that I get more traction with the following variation on the model.
And I think of them as follows:
- Table Stakes – those problems your product addresses, which your customers view as mandatory. If you don’t address them, your product isn’t even considered as a possible solution.
- Competitive Jockeying – these are the problems where one product is trying to provide “better” solutions than the other products, in a bit of a horse race for market leadership.
- Differentiation – these are problems where, if solved, they would differentiate a product from the competition. Think “blue ocean strategy” here.
- Disruption – these are problems where, if solved, effectively redefine the market – disrupting existing players. These are the game changers.
I believe this keeps with the spirit of what Mr. Levitt was getting at with his model. Or at least it aligns with what I took away from it. Any misrepresentations are my own, but please let me know in the comments if your brain went in a different direction after reading his article.Classifying Problems Using This Model
I was doing an exercise with a team, reviewing their current roadmap as part of the budgeting cycle. The roadmap was what the team were proposing, and hoping to get funded. This is a team which historically was more “inside out” in their thinking, and needed to be outside-in (market driven).
The question I wanted the team to answer was how does this investment make your product more competitive?
Ultimately, that’s what you’re going for – either strategic positioning of some sort, or an investment driven to improve your product.
I put the four categories on the whiteboard, and the team members identified market problems (which were part of their product) and mapped them to each area. At first, the team struggled to get started, with a bit of writer’s block. We broke the logjam by identifying a feature which the team would ordinarily focus on. Then we identified what market problem the feature was intended to address. Once we had a problem identified, we could add it to the board. Then we picked another feature, and did the same thing.
It would have been much easier to just identify the features. The problem is that customers don’t care about features – they care about solving problems. If you focus on the features, you can lose sight of the problems. You may also fail to identify a competitor, who addresses the same problem with a different feature.
As an example, someone who sells tanning booths may really focus on the features that maximize the surface area being tanned, or the air-flow in the booth, competing on speeds and feeds with other booth vendors, and companies who make tanning beds. They might easily be blindsided by the rub-on or spray-on tan products, who end up disrupting their markets. The problem is that the booth vendor focused on features (coverage, temperature, etc), instead of problems (skin is not dark enough).A Holistic View of Your Market
In the whole product game, we’re using divergent thinking and brainstorming to explore a problem space. This exercise, classifying market problems is a convergent thinking exercise. We capture our current understanding of the market, for the purpose of seeing how well our product is positioned to address the known problems.
There are some interesting variations / analyses / discussions which come up during this exercise:
- With the current plan, are we trying to get “a bit better” in many different directions, or really focusing on solving a single problem, for a specific market segment?
- Now that we’ve classified these problems – which ones are more important than others, for our target customers?
- How do we compare with our competition at providing solutions to the most important problems? Are we investing to catch up? Or to pull ahead? Or are we trying to disrupt an existing market with something new and compelling?
Many teams struggle with backlogs or roadmaps which appear to be a collection of “a bunch of stuff.” Most teams try and address the problems that manifest from having a giant list of stuff by getting better at managing giant lists. This is treating the symptom, not the cause. If you’re trying to juggle hundreds of requirements, the problem isn’t that you have hundreds of requirements, the problem is that you don’t know why you have requirements.
The investments into improving a product should be intentional. Every item on the backlog improves an aspect of the product – but to what end? When you identify the problems the product is intended to solve – an outcome of doing this exercise – you have a framework for mapping or tracing every backlog item back to the goal (problem) it supports.
Those hundreds of requirements probably all trace back to a few specific tangible problems. As a fun tangent – that’s the basis for forming a good roadmap too.Many Lenses
When you’re reviewing a roadmap in light of a strategy, there are several different ways you need to look at your plan. One of them is to understand how it is you’re trying to compete (by being better, being cheaper, inspiring aspiration, or something else). How complete are your solutions, how important are the problems you focus on? How does your product compare with competitors?
This is one of the views I use to get a sense of where a product plan “is” and very quickly identifies how (and how well) a team understands their market.
David's recent post Kanban Litmus Test prompted an interesting question on kanbandev: How does Kanban apply if you don't have an existing process to change?
My first experience of Kanban was with a team that was still coming together. It was less start with what you do now, more start with a rough understanding.
This fall, we are introducing a new curriculum to our class offerings - Project Management with Kanban. Note the subtle choice of title - "Project Management with Kanban!" It isn't "Kanban for Project Managers." Kanban for Project Managers makes as much sense to me as "Kanban for Refuse Collectors" Why would such a class be different from say, "Kanban for Grandmas"? It's all just Kanban! Perhaps the case studies and examples might be different but the curriculum would be the same. On the other hand, Project Management with Kanban" offers us the chance to provide a new curriculum, specifically targeted at managing project where kanban systems are in use and the Kanban Method is part of the organization's management approach.
Two of the twelve Principles Behind the Agile Manifesto are about people working together in close daily collaboration.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
In a well functioning Agile team, this collaborative connection is the fuel that propels the team’s success. As an Agile coach, I love being able to coach a team that sits together, is able to connect in person throughout the day, and can effortlessly pull together to solve problems. But in a world where good developers are in short supply and in high demand, and where work/life balance becomes ever more important for being able to hire and retain good employees, allowing people to work from home is a fact of life for companies today.
How do you enable collaboration when team members are working from home?
How do remote teams engage in stand up meetings, sprint planning sessions, retrospective meetings, and other Agile ceremonies?
You just have to leverage the right tools.
Some are obvious. Online meeting tools such as Webex, GoToMeeting, Google Hangouts, and Imeet are essential. Use these for stand-up meetings and for planning and review sessions where you need full team participation.
If you are using VersionOne to help manage your Agile process, consider the team room capability that it provides to drive your stand up meeting. Don’t make the mistake that some teams make after they experience success and start to feel comfortable. Avoid the temptation to drop off important ceremonies, like the stand-up meeting. I’ve coached teams who had a handful of good sprints, and felt that perhaps they no longer needed to meet in person and could just email in a daily update. Bad idea.
Internet Relay Chat (IRC) and Google Hangouts work well to keep the team engaged together and collaborating throughout the day. The key is to do group chat as opposed to individual chats. Let the whole team monitor the chat room as a way to stay in contact with each other. While this is certainly not as powerful as team members being able to roll their chairs to the middle of the team room to talk, it can nevertheless be quite effective.
I use a tool called Notepp for running team retrospectives with remote team members. Noteapp allows you to create an interactive retrospective board and publish a URL to the team. You can watch the whole team contribute ideas to the retrospective in real time as they type notes on the board, almost as if you were doing this together in a conference room with sticky notes.
Co-locate teams if at all possible. The payback to doing so is significant. But if you’re going to be Agile in a remote workplace world, get the right tools in place to support the team’s ability to collaborate.
Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.
If you missed the webinar, view and download the slides.
Want an overview of Fast IT in 60 seconds? Watch the video below:
Get notified about new and exciting content around Fast IT by completing the form below:
The 4-Step Action Plan for Agile Health: Step 4: Develop and Implement your customized plan for adopting healthy agile-lean practices
Agile development requires a cross-functional, self-organized team to deliver potentially shippable software at the end of each sprint, with analysis, design, code developing and testing activities going on concurrently (not sequentially) within each sprint. Combining Agile/Scrum development with some of the lean methods is also becoming popular (so-called “Scrumban” methods). These methods emphasize reducing Work In Process (WIP), reducing feature cycle time and increasing throughput (feature completion rate).
In my blog on From Agile Pathologies to Agile Health I explained that some “agile” teams suffer from the following common pathologies, i.e., major dysfunctions in practicing agile methods, while claiming that they are “doing agile”:
- Agile development “sprints” assigned to software development lifecycle phases
- Agile development “sprints” assigned to technology tiers
- Mini-Waterfall inside sprints
While an agile team may not be exhibiting gross dysfunctions (pathologies) listed above, it may still behave in harmful or unhealthy ways that would prevent it from realizing the benefits of agile development, such as higher productivity, throughput and quality. Absence of major pathologies or sickness doesn’t imply health; agile teams may still not be healthy due to one or more harmful behaviors.
In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality). I also present 4 specific steps to transition to healthy agile-lean practices. Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: Part 1, 2 and 3 (highlighted in light green color) were completed. In this Part 4 (highlighted in pink color), Step 4 – develop and implement your customized plan for adopting healthy agile-lean practices – is described.
Table 1: The 4-Step Action Plan for Agile Health
Sprint History Map: In Parts 1 to 3 of this blog series, I presented and extensively used Sprint History Map as a visual metric to understand what has happened on each day of a sprint timebox and to derive many useful data points to help us understand the health of an agile team:
- Cycle time for each accepted feature and the average cycle time
- WIP for each day of the sprint for accepted features in the sprint, and their average WIP
- Throughput (feature acceptance rate per day or per time unit) – calculated from 1 and 2 above using Little’s law; this number can be visually verified easily on the Sprint History Map
- WIP for each day of the sprint for all features (accepted as well as not accepted) worked on, and their average WIP
- Specific days when regression testing was done during the sprint (if any)
- Planned number of features and their total story points
- Velocity: Accepted number of features and their total story points
- Number of NT and IMP events, and their total. These are the days when work stoppage occurred.
Many Agile Lifecycle Management (ALM) tools have a data warehouse facility for storing historical data, and analytics tools to generate reports from the historical data. Ideally a single analytics report (or a small set of few reports) should present all the data listed above in a visually simple way to understand. It might require some programming effort using the tool’s APIs. You may check with your ALM tool vendor if this is possible, and seek vendor help to generate Sprint History Maps. Otherwise, you may have to put some effort to gather different historical data items or reports to piece together your version of the Sprint History Map.
Sprint History Map is a very useful visual diagnostic tool that offers a number of critical insights indicating the health of an agile team, how effective its practices are, and how much dysfunction exists in its agile practices, etc.
Recommended approach for moving away from harmful behaviors and adopting healthy agile-lean practices: Each team and organization is unique, and therefore has unique challenges and opportunities to move away from harmful behaviors to adopt healthy practices. Your approach should be customized to your specific situation, constraints, needs and goals.
It is helpful to organize 6 harmful behaviors and the corresponding 6 healthy agile-lean practices along 3 dimensions (X, Y, and Z) as shown in Figure 1. X-dimension covers transition from manual testing to test automation, and from “frequent impediments and non-availability of qualified team members” to “effective impediment management and full availability of qualified team members”; Y-dimension covers transition from “non-lean” behaviors to agile-lean practices; and Z-dimension covers transition from “legacy mindset” behaviors to agile mindset practices. For each transition (from a harmful behavior to a healthy practice) to succeed, I have also indicated the degree of senior management and functional management support likely to be needed along X, Y and Z dimensions.
Figure 1: 6 Harmful Behaviors and 6 Healthy Agile-Lean Practices organized along three dimensions including the degree of senior management support needed
I recommend launching an immediate effort along the X-axis by embracing test automation practice, both unit test automation with test-driven development discipline, and acceptance test automation. Both practices will need training. Get help from qualified coaches, and relevant training courses and books. No team can migrate from the manual testing norm to fully automated testing practice in few sprints. Test automation will require serious commitment and effort over several release cycles to get more and more test cases automated, and thereby building a growing suite of automated regression tests. As explained earlier, without regression test automation, fully tested, potentially shippable software for every sprint is not feasible. It is imperative to get started on the test automation practice and gradually minimize the manual testing effort. Clearly, some types of testing that require human judgment, such as usability testing, cannot be automated.
Effective impediment management can be learned with practice and improved with process maturity and experience; management support is still needed for removing organizational impediments. As multiplexing and multitasking reduces, and the team starts following Stop-Starting-Start-Finishing lean mantra, the number of NT events should reduce over a period of time. Moving away from non-lean behaviors (3B and 4B) to healthy agile-lean practices (3P and 4P), shown along the Y-dimension of Figure 1 is a challenge that can be addressed at the team-level. It usually doesn’t depend on and need not wait for senior management support. I suggest starting with training and workshops on lean methods from qualified coaches. A number of good books and web resources are also available.
Moving away from legacy mindset behaviors (1B and 2B) to healthy agile mindset behaviors (1P and 2P), shown along the Z-dimension of Figure 1, is likely to require a high degree of support from senior management and functional management because it is probably the most dramatic change in a hierarchically structured, waterfall organization. Only the senior managers are in a position to move an organization from multiplexing/multitasking behaviors to instituting and empowering cross-functional, self-organized agile teams consisting of full-time, dedicated team members. If you believe getting support from senior management would be a significant challenge in your organization, I suggest starting with agile-lean training for executives, where they could understand how their role changes to support agile-lean adoption, and what they will need to do differently.
You should assess which specific current behavior(s) produce the most pain, which new practice may produce the most benefits quickly, and the degree of support needed from senior management. Some of this assessment can be done qualitatively in discussions among the team members and stake holders. This qualitative assessment should be supplemented with measured quantitative data for one or more agile teams in your organization. I recommend taking a look at your team’s most recent Sprint History Maps (typically the last 4 sprints) to assess its current state.
Does your agile team’s Sprint History Map look more like a healthy agile team’s map (as shown Figure 2 of Part 3)? Or does it look closer to the map of a struggling agile team (as shown in Figure 1 of Part 3)? A careful analysis of your team’s Sprint History Maps will provide quantitative data, such as the cycle time, WIP, throughput, velocity, number of IMP and NT events. I suggest doing this analysis for the last 4 sprints, if you have that data available. In addition, I suggest analyzing more traditional reports for your team, such as sprint burn-down and burn-up charts, and cumulative flow charts to identify problem areas, if any. For example, if the sprint burn-down charts show flat horizontal lines, they might be caused by IMP and NT events (but not always). If the sprint burn-up charts show most features getting accepted towards the very end of a sprint, it may indicate that the team is not following the Stop-Starting-Start-Finishing lean mantra and has no WIP limit for its work.
With this information (qualitative as well as quantitative) you can assess your current situation, and perform a gap analysis, i.e., determine the gap between the desired goal state at some time in future (say six months from now) and the current state. Based on this gap, you should then decide and implement the course of action: where is the biggest return on investment would be, i.e., the most benefits for the least amount of effort or time.
Table 2 summarizes the transition from 6 harmful behaviors to 6 healthy agile-lean practices. It also summarizes several recommended possible actions that you may choose from to implement your customized action plan.
Table 2: Transition from harmful behaviors to healthy agile-lean practices
Expected challenges and suggested actions
How does your History Map look? Are any of the 6 harmful behaviors causing serious challenges and issues in your organization? Are any of the 6 healthy agile-lean practices giving your team tangible benefits? Are you interested in developing and implementing a customized approach for your transition from harmful behaviors to healthy agile-lean practices?
Part 1: Understand harmful legacy Mindset and Non-Lean behaviors to move away from
Part 2: Understand healthy Agile Mindset and Lean Practices to adopt
Part 3: Understand how to use additional enablers of Agile Health
Here is the deck from my Agile2014 workshop on Personal Kanban.
Participants will be introduced to the principles of Lean and the application of Kanban to visualize their work, limit distraction and waste, and get stuff done. I’ll cover the core concepts outlined in Jim Benson and Tonianne DeMaria Barry’s book, Personal Kanban, to get you started.
If you come/came to the workshop, I appreciate it. If you have any questions, please let us know. Thanks!
Der Scrum-Day 2014 war so ernüchternd. Ich kann es euch gar nicht sagen. Ich oute mich jetzt sicher als ewig Gestriger mit meinen mittlerweile 45 Jahren. Vielleicht waren die 68er genauso, die einmal Ideale hatten und dann in der Grünen Bewegung konsumiert und zum Mainstream wurden. Aber was da gerade passiert, ist erbärmlich.
Wir reden auf einer Konferenz, die den Anspruch hat, die bedeutendste Scrum-Konferenz in Deutschland zu sein, über Modelle anstatt über die Realitiät. Es gibt Beiträge über skalierende Frameworks, von Menschen, die das vorstellen, weil sie es gelesen haben. Und selbst die wundervolle Lisa erklärt uns ein Coaching-Modell, aber nicht, wie man in den USA agile Transformationen durchgeführt hat. Die berühmten Leuchttürme fehlen.
Ich liebe Modelle – als Philosoph, Soziologe und gescheiterter Physiker bin ich absolut fasziniert von Erklärungsmustern. Aber sie helfen nicht, die echten Themen bei agilen Transformationen in den Griff zu bekommen. Ob es Entwicklungsteams oder Management-Teams sind: Sie werden sich nicht bewegen, weil man ein Bild an die Wand wirft, in dem Boxen und Pfeile erklären, wie man miteinander arbeiten soll. Sie suggerieren denen, die sie anschauen, dass der Erzählende Ahnung davon hat. Doch wovon? Davon, wie man als Redner und Autor eine Menge fesselt. Doch sind das die gleichen Skills, die man braucht, um ein Unternehmen agil zu machen?
Ich wurde von einem großen Unternehmen angerufen: “Wir wollen 6000 Menschen in 2,5 Jahren hin zu agil transformieren.” Leute: Das hat noch niemand gemacht! Da helfen keine Modelle. Da hilft auch nicht das Wissen aus allen Change-Management-Büchern der Welt, sondern nur das, was die, die das agile Manifesto geschrieben haben, taten: Die Ärmel hochkrempeln und sich der Realität aussetzen.
Unternehmen mit der Mitarbeiterzahl ganzer Dörfer oder kleiner Städte, verteilt über die ganze Welt, können nicht geplant und ad hoc dazu bewegt werden, ihr gesamtes historisch gewachsenes Wissen über Zusammenarbeit zu verändern. Diese Aufgabe als Projekt zu sehen, vielleicht auch noch mit einem Enddatum versehen, ist schlicht vermessen. Es widerspricht außerdem der Idee von agilem Arbeiten und agilen Organisationen.
Der Weg zur agilen Organisation funktioniert anders – ohne Modelle und ohne das fertige Konzept. Durch eine starke Führung, die Orientierung gibt, die neue, funktionierende (agile) Arbeitsweisen vorlebt, die deutlich macht, dass es um das Erfüllen von Anforderungen der User geht und die es schafft, neue Formen der Zusammenarbeit zu ritualisieren. Menschen lernen durch Abschauen dessen, was funktioniert. “People are good in looking around”, schrieb Alistar Cockburn vor einem Jahrzehnt dazu. Er hat recht – also müssen wir Modellwerkstätten bauen, in denen das neue Arbeiten funktioniert, oder dorthin gehen, wo es schon funktioniert und von dort Ideen mitbringen.
Es wird sich wie immer das durchsetzen, was funktioniert – das ganz simple Prinzip Darwins. Das haben Produkte wie SMS gezeigt, What´s App, das Internet, das iPhone und die Demokratie. Implementiert einfach ein paar Praktiken, werdet selbst zum Modell für agiles Arbeiten, seid damit erfolgreicher als zuvor und redet darüber. Langes Erklären führt meist in die falsche Richtung.
Guest post from David Nicolette, agile coach at Eliassen Group
I’m one of six technical agile coaches engaged by a large bank to support an initiative to improve software delivery performance. The IT department is an established agile software development shop that uses the SAFe™ framework with Scrum at the team level. They are seeking to achieve continuous delivery, improve software quality, establish a developer-friendly working environment, and foster a culture of continual improvement.
We want to be able to show the effects of changes the teams make in their working practices. Improving delivery performance involves changing the way people work; therefore, we need measurements that aren’t dependent on doing the work in any particular way. Three metrics from the Lean school of thought are helpful: Throughput, Cycle Time, and Process Cycle Efficiency (PCE).
It isn’t the purpose of this post to explain these metrics, but here’s a quick summary. Cycle Time is the time it takes to complete one work item. Throughput is the number of “value units” delivered by the process in a given unit of time (say, per release or per month). Process Cycle Efficiency (PCE) is the proportion of total lead time in which value is added to the product. If we take a look at these measures at the start of an improvement initiative and again at the end, we can see whether the organization has improved its delivery performance.
To adapt these metrics to software development, we need to adopt somewhat softer definitions of “work item” and “value unit” than what is usual in the manufacturing domain. For our purposes at this client, a “work item” is a User Story, the type of work package used with the Scrum framework. A “value unit” is a software feature. While these things can be somewhat loosely defined and can vary in size, these working definitions are sufficient for our needs.
It’s easy enough to get Throughput using the tools they are already using. We can get a crude sense of Cycle Time from their agile project management tool by subtracting the start date from the end date of each work item, but we want a little more granularity than that so we can show the effects of external dependencies, back flows, meetings, and context switching on Cycle Time. It can be difficult to get meaningful PCE out of some project management tools, so we need to collect the raw data for that as well.
To show the impact of changes in team structure, delivery process, and technical practices on delivery performance, we want to compare these measures at the beginning and end of the coaching engagement. We’d like to see Throughput and PCE increase, and we’d like to see mean Cycle Time and Cycle Time variation decrease.
Generally speaking, increased Throughput means the teams are delivering more software in each release than they were previously. Increased PCE means the teams are spending proportionally more of their time adding value than they were previously. Reduced Cycle Time means the teams are able to complete work items in less time than previously. Reduced variation in Cycle Time means the teams are learning to decompose work into similarly sized User Stories, and/or they have eliminated some of the blockers that had been present in their process. Reducing variation in Cycle Time improves planning predictability, which usually leads to greater stakeholder confidence in the teams and higher trust across the organization. In turn, those factors feed back into delivery performance in a positive way.
You may have noticed that there is no mention of comparing estimates with actuals. This is an entirely empirical approach. Observed actual performance is of interest. Optimistic stretch goals, coerced commitments, and guesses are less informative than empirical observations. These teams follow the usual Scrum ceremonies and practices, including relative sizing of User Stories in terms of Story Points and estimation of tasks in terms of hours. We do not find that information useful for understanding the effectiveness of software delivery.
Collecting the Raw Data
The typical way to collect baseline numbers for these metrics is to conduct a value stream mapping workshop that involves most or all team members for one day or longer. The client is worried about losing too much time in the workshops when the teams could be doing value-add work. Therefore, we needed a less intrusive way to collect baseline measurements. There is also the question of how accurate the PCE data will be when it is obtained through a workshop, rather than by direct observation of team activity.
I came up with the idea of using Lego bricks to collect the raw data for Cycle Time and PCE. There is some impact on team member time, but hopefully it is not too intrusive. My observation is that people enjoy manipulating Lego bricks, and they don’t mind sticking the bricks on a plate to represent their work.
For each team, we set up a Lego plate large enough to hold about 10-12 1″×2″ bricks. We allocate one row of bricks for each User Story. For each hour in the day, team members place a green brick when they performed value-add work on the User Story, and a red brick when the User Story was in a wait-state during that hour. A 1″×1″ white brick is used to show User Story completion. We don’t worry about counting minutes. At the end of each day, we collect the data from the Lego plates in a spreadsheet and remove all the bricks for a fresh start the next day.
Here’s how the Legos looked at the end of the first day for the first team that set this up:
Each team tweaks the setup in their own way. In this case, the row of black, blue, and yellow bricks across the top of the plate represents the hours of the day. Black and blue colors alternate for visual clarity. The yellow brick represents the lunch hour. User Stories are identified by their key in the team’s project management tool.
From the state of the Lego bricks, you can see that the team had six User Stories in “in progress” state. For the first one, value was added during one hour out of eight. There are no 1×1 white bricks, which means none of these User Stories has been completed.
At the end of each day, I collect the data from the Lego plates and accumulate the values in a spreadsheet. Here is how the spreadsheet looked when I had entered the data from the board above:
After capturing the data in the spreadsheet, the Lego plate is cleared and we start the next day with a clean slate. There is no need to extend the Lego bricks indefinitely, as we are interested in accumulating Cycle Time observations and not in building up a physical history of User Stories in the form of Lego bricks.
Here is how the board and spreadsheet for the same team looked after the second day of collecting data:
What we do with the information
The plan is to collect this information for a couple of sprints at the start of the improvement program, and repeat the collection again for a couple of sprints toward the end of the program. We don’t want to create an ongoing administrative task for team members. We are interested in:
- Mean Cycle Time – average time to complete a User Story
- Common cause variation – variation within one standard deviation indicates common cause variation; that is, variation that is caused by systemic factors (organizational or team structure, process steps, technical practices, etc.). This can point to potential structural or procedural improvements.
- Special cause variation – variation beyond one standard deviation indicates special cause variation; that is, variation that results from unusual events or one-time problems. This can help us define policies to deal with unexpected issues in a way that doesn’t significantly impede continuous flow.
- Clustering – Cycle Time observations may settle out into multiple clumps. This indicates User Stories that have certain characteristics have a different effects on Cycle Time. For example, User Stories that have dependencies on external teams or outside vendors may tend to have longer Cycle Times than User Stories the team can fully control. Understanding the impact helps us perform short-term planning effectively.
- PCE – low PCE may point to “time sinks” in the process that we can address. External dependencies are an obvious cause of wait states, during which no value can be added to the User Story in progress. Wait states may also be caused by team structure, when teams of specialists are organized in silos, and multiple teams must be engaged to complete a single User Story. Context switching due to high WIP is another obvious cause. It’s useful to be able to make these effects visible, as people are more willing to address underlying issues when they see evidence than when they just hear words.
We are more interested in aggregate numbers than in individual User Stories. Mean Cycle Time (possibly broken out by categories of stories) helps with short-term forecasting. Beyond that, we can look for opportunities to shorten mean Cycle Time and to reduce variation in Cycle Time to improve continuous flow.
Here is a generic example of a chart we might generate from observations of Cycle Time. It is not based on the specific teams mentioned here — we haven’t been collecting data long enough to develop this sort of visualization.
Two of the four teams involved in this have embraced the idea openly, and the other two are hesitant because they have not yet seen how it might help them. The two teams that have embraced the idea started to change their habitual behaviors almost immediately, as soon as the wait states in User Stories became visible.
1. Immediate reaction to impediments
It’s commonplace that when something is made visible, people act on it. I was surprised to see the natural response when a team member reaches for a red brick. Others on the team immediately ask what the impediment is and how they can help. These were already practicing “agile” teams, so they are already stable teams working in team spaces, and collaboration was not a new concept at the start of the engagement. However, the immediacy of their reaction to seeing a red brick is a radical improvement in the speed with which teams respond to emerging issues.
You might point out that basic “agile” practice includes posting an indicator on the User Story card on the team’s wall as soon as an impediment comes up. These teams are not in the habit of doing that, so there is typically a delay before the team begins to act on impediments. A couple of these teams did not have a card wall at all when we started working with them. They believed their electronic project management tool served the same purpose as an information radiator, which is not always the case. The organization has been using “agile” methods for several years, but not every team does every little thing to perfection.
2. Limiting WIP
A second natural reaction to the boards is that when a team notices a large swath of red on their board, they start exploring the reasons why. Without any formal training in Lean concepts, they quickly conclude that they have too many User Stories in play. They limit their WIP, even without knowing that term. Before the impact of high WIP was visible, team members often said they did not understand the “big deal” about pulling just one or two User Stories at a time.
Management looks at the burndown charts and cumulative flow diagrams (CFDs) for each team. Nearly all teams in the organization have the classic “hockey stick” burndown chart, and a CFD that looks like a single block of color representing “in progress.” The teams that have started to notice the impact of high WIP thanks to their Lego boards are already starting to show burndowns that look like actual burndowns. They are pulling User Stories through to completion rather than starting everything on the first day of the sprint. Within days, it became a sort of game to see if the team could eliminate all the red bricks from their board.
3. Tracking unplanned work
A third reaction has to do with “user stories” that are not really User Stories. Many of the teams in this organization define “user stories” as placeholders for unplanned work. Scrum is generally good for managing planned work — the Product Backlog lists features to be developed in priority order by business value. Each Backlog Item is decomposed into one or more User Stories, which can then be pulled into Sprints for development.
Teams that service requests from other teams do not know in advance when the other teams will request services. The requests are not in the Product Backlog. As an expedient to fit this into the Scrum framework, they define pseudo-stories where they throw in “tasks” when other teams submit requests for services. They try to account for the impact by setting aside a portion of their available time each sprint to handle whatever unplanned work may come in during the sprint. This tends to throw off their sprint forecast, but they can’t think of another way to account for the work that is consistent with their understanding of the Scrum “rules.”
A consequence of the practice is that these “user stories” appear to have Cycle Times equal to the Sprint length and to spend almost all the time in a wait-state. This is because they are ongoing, open-ended “user stories” that can never be completed, and most of the time there are no unplanned requests in progress. If they continue to do this, their Cycle Time metrics will be skewed. Making Cycle Time visible causes these teams to reconsider the way they define and track unplanned work.
Without prompting, some people have suggested moving to a Kanban system that supports explicit policies for different classes of service, rather than trying to define every type of work as a User Story. Others are considering allowing urgent “stories” to be added mid-sprint and having the Product Owner remove scope from the sprint backlog, as per standard Scrum practice. The important thing is that they are thinking about better ways to manage unplanned work.
4. Manager response
The managers over the Release Train were very interested in how Cycle Time and PCE were being used. I explained what the metrics mean and how we intend to use them to show progress with the process improvement goals. I took them on a tour of the four team areas and they saw how the Lego boards had been set up. They asked team members whether this was helping them, and got mixed, honest answers. The managers noticed that some teams routinely work through the lunch hour and some routinely work 10-hour days. They expressed to the teams that they don’t want them to burn out and they want to figure out ways to get the work done in a sustainable way during normal working hours. This had a positive effect on team morale.
The managers were just as interested in playing with the Lego bricks as the team members. They suggested various changes, using additional colors to represent details about wait states. I suggested that we keep it simple. We don’t want to turn this into yet another administrative overhead task for the teams. I think I convinced them that we only want to capture the wait times, and leave root cause analysis for later.
5. Micromanaging time?
A couple of people voiced the concern that we were asking individuals to keep track of how they spend their time. The organizational culture is such that management expects people to get their work done, and does not track when, how, or where they work. I had to clarify that this is about tracking time from the point of view of a User Story, and not from the point of view of any individual person. We want to expose time sinks so that we can help management change the organizational structure and formal procedures in ways that make life better for development teams. Once that was clear, people were not opposed to it.
Please let us know what you think below!
“Everything is so chaotic.”
“Seems like we are constantly in a state of chaos.”
“Is agile always crazy and chaotic?”
Chaos is a word I hear a lot lately while working with software development teams that are either initially adopting agile software development or possibly undergoing a Lean/agile reshaping to improve their existing agile development approaches. I am often asked if the chaos will subside, and the good news is it will — to a certain extent. But to best understand when things will slow down (or even if they’ll slow down), it’s good to explore some of the causes that make things chaotic with agile software development.
And in my world, there’s no better way to assess than to make a list of Top 10 causes of chaos in agile software development:
1. New Teams Forming.
This one is obvious — as people come together to work with one another there’s a feeling-out period. Usually during this period, teams are learning how to collaborate and work through conflicts. In addition to the people learning to work with one another, there are plenty of established organizational structure and cultural barriers that slow the progress of agile teams forming.
2. Process Learning.
Another obvious one. Although most agile process frameworks (e.g. Scrum or Extreme Programming) are fairly easy and well documented, it takes time and practice to learn the mechanics. Couple this with #1 and, well, there can be some real challenges to getting things done.
3. HEAVY Learning Mode.
This may seem redundant, but it really cannot go under emphasized. In addition to learning about each other and learning the process frameworks, as engineers — we are constantly learning about technologies, learning about our products, learning about our customers, well — just getting smarter. Needless to say, this all adds up.
If you ever have watched the Deadliest Catch on The Discovery Channel, you get to see the struggles and pains of the first-time deckhands – called Greenhorns. They are often in way over their heads, running into challenges around every corner, and are just flat out exhausted. In addition to physically and mentally killing themselves, they are trying to prove themselves. Well, this is true with just about every new team member. Not only are they dealing with Items #1-3 above, the intensity of learning is magnified; until they have some wins and time under their belts, chaos exists.
5. When Quality is NOT Built-in.
It is my opinion that in software development, over the years we’ve invented this approach to quality that is “risky and invites failure.”  Yes, I stole that — in most software development shops, quality is something that is done by different people to ensure “separation of duties” and because of the mentality that ‘developers make bad testers.’ Couple that with the attitude that QA engineers can’t, or don’t necessarily need to know how to code, we have what we do today — a ton of end-of-stream testing, out-of-band automation efforts and, honestly, even the staunches of agile shops struggling with testing and ensuring quality. Without quality weaved into the Design>Build>Test cycle, we tend to see a lot more of these noisy things called Defects. Defects take a ton more time and energy than building it right in the first place.
6. Quality Automation Doesn’t Exist.
Without automation you’re going to find it almost impossible, or at least extremely constraining, to effectively and efficiently deliver software quality in a predictable manner. Similar to the “build quality in” challenges, teams often struggle because their estimation processes call out quality separately (which makes it a target for evil doers), and it often does not account for the work-around automation. Many organizations adopting agile software development don’t have an automation strategy for their legacy code. Therefore, they tend to have bouts of analysis paralysis around the problem space or they simply say, “our product or software is too hard to automate the testing” — so they won’t try. The other challenge around automation is that some see it solely as an end-of-line UI automation thing where a couple engineers work on it. Test automation is a holistic challenge and needs to be treated as such.
7. Lack of Cadence.
When teams are starting out, they don’t realize that the first thing to establish is their cadence — get their schedule in place and timebox everything. The cadence surrounds the process touch points that require formal communication and help us to build habits, thus making the process aspects of agile software development more muscle memory. If you feel like you are always in meetings or your iteration meetings are not occurring at the same Bat-Time and same Bat-Place, it might be time to reset; your cadence is lost.
8. Unpredictable Release Cycles.
This one is an enigma because there are teams I run into that say, “Our product is too large and complex to release in short cycles.” And then there are those that say, “We just release when we have to, it could be twice today or two weeks from now.” Looking at these two statements, they appear to be opposite in cause; however, it all comes down to #7 above and understanding what is the ideal batch size that reduces thrashing allows for tighter alignment among teams; reduces “Integration Hell;” and prevents the amoeba-style releases that never seem to end.
9. Deadline-Rich Environment.
Projects are the problem — or at least the traditional sense and meaning of a project drives the idea of fixed scope and fixed schedule. Let’s look at the PMI’s definition of ‘a project’:
A project is a temporary group activity designed to produce a unique product, service or result.
A project is temporary in that it has a defined beginning and end in time and, therefore, defined scope and resources.
At the end of the day, we drive our business off of the idea that of pushing for a date — we get emails from colleagues asking “when?”, we get emails from tools telling us “now!”, and we have other teams telling us “yesterday!” Ultimately, projects drive expectations that are generally dates; we can’t seem to get away from them until everyone realizes that we should design and define the scope to fit the schedule, not the schedule to fix the scope. This is because the schedule usually flexes in these situations, not the scope.
10. Estimation (and For That Matter, Capacity) is Not Understood.
We often see teams measuring productivity units of time versus being measured as units of value. This is the case even in mature agile shops. Everyone is so focused on trying to come up with a voodoo formula to determine capacity of a team or organization and another voodoo formula to normalize story points across teams in order to build a long-term plan based on the cooked-up numbers. The funny thing is that in many cases, the approach used for estimation doesn’t really change once an organization starts using agile. Everyone continues to plan predictively what we really don’t know. Agile software development is an adaptive approach to estimation and capacity. We work with what we know, we measure value, we assess complexity, and we often simply size efforts based on relative uncertainty. If people would just keep it simple, try to get all stories to the same level or near the same level of certainty, and do the same with the to-do’s (a.k.a. tasks and tests) — then in a couple iterations, teams could just count the stories and count the to-do’s accomplished within a timebox and use that for planning. Oh, if only it could be that simple … it is.
Okay, this was just my brainstorming or brain dump (literally) of 10 things that cause chaos in software development, in particular in the situations where an agile adoption or reshaping is underway. Just keep in mind, change is constant in business — now, more so than ever. Software development is complex; so are people. The great thing about tomorrow is that we don’t know what is going to happen. So, just practice and keep in mind: if today is bad — then there’s tomorrow.
Agile promotes that teams work in a sustainable pace to be able to keep delivering value to their customers. When agile teams are working under too much pressure, technical debt increases and the velocity and productivity of teams goes down. Agile retrospectives can help you to discover the causes of pressure and take actions to establish a sustainable and healthy pace with your teams.
A sustainable pace is a workload which a team can handle for a longer period, without compromising the quality of the product. It is based on a velocity that is doable for the team and doesn’t lead to stress or illness of the team members. Organizations can deploy agile processes that give teams flexibility to self-organize their work to manage their workload and flow.
When the workload of the team becomes too high, chances are high that team members will make more mistakes with increased technical debt as an result. Team pressure drives code quality down and increases maintenance. Due to the technical debt, the velocity of the team will decrease so they will actually be delivering less value to their customers while putting in more hours. Clearly a waste of valuable time, money, and energy of your people.
Finding the causes of team pressure
Some pressure is acceptable, but if you have the feeling that you are always working under pressure,the pressure is hampering your teams to deliver value to your customers, and the low quality of your products is costing you money, then that is something that should be addressed.
You can do that for instance with valuable agile retrospectives, by using exercises where team members state how they feel things are going. Facilitators can ask questions to discover what can be done to reduce the pressure. A retrospective can also be used to find the root causes of team members feeling constant pressure. You can do a five times why exercise to investigate the deeper causes of pressure.
How do you find out if teams are under pressure and what causes it? Here are some things coaches can focus upon in retrospectives, daily stand-ups, or in mentoring and coaching sessions:
- Do teams get enough freedom to do the work in the way they think it should be done?
- Are team members allowed to fail or make mistakes? Is it ok to learn from them?
- Is it just 1-2 people who are under pressure, or is it everybody on the team?
- How is the morale of your teams? What’s the atmosphere at work, and how do people react to each other?
- Do team members feel happy when they come to work, and when they go home?
Once you’ve identified that teams are under pressure and have learned what causes it, then they can take actions to address it in a next iteration.
Establishing sustainable pace
If a large workload is causing too much pressure and hampering teams, then they should take action.
Possible actions that they can take are:
- Commit to a lower number of user stories in the planning game. Build in slack.
- Investigate which improvements they can make to increase team velocity.
- Establish stable teams that are capable of delivering quality and maintaining high productivity.
- Prevent multitasking/task switching as much as possible.
- Monitor work in progress; use Lean and Kanban to steer on flow instead of working more hours.
- Plan time for team members to relax and blow off steam after having had a busy period.
- Focus upon happiness in your teams; make sure team members have fun while doing their work.
It’s important to follow up on the actions to verify that the pressure decreases so that teams can work in a sustainable pace. An effective way to do this is by doing short-cycled improvements: Observe how the team is doing in their daily work. Use opportunities to change the way of working to improve in small steps. And turn that into a new way of working for the team.
Collaborate with your stakeholders
It may be good for teams to involve their stakeholders to find workable solutions to reduce the pressure and find a sustainable pace that delivers value to them. Teams may have the opinion that stakeholders are causing pressure, which indeed can be the case. But often stakeholders are not aware that they are putting teams under too much pressure. Teams should discuss it with them, make them aware, and together look for solutions to decrease the pressure.
Building trust is important: The stakeholders should trust the teams by assuming that they will do the best they can, and the teams should secure this trust by continuously delivering valuable products. In the longer run, both the teams and the stakeholders will benefit from a sustainable pace by getting more value.
“If you want to deliver more, you should not work harder, but smarter” is a basic thing that didn’t change when agile was coined. Self-assessing how agile you are and doing smaller changes that stick using feedback and learning cycles from agile methods like Scrum are effective ways to implement lasting improvements. You need to invest time and energy, but when properly done, it certainly pays back. It helps you to stop death marches and to work in a sustainable pace.
Guest post by Ellen Gottesdiener and Mary Gorman of EBG Consulting
Recently we worked with an agile team that was building an FDA-regulated medical device. Some team members were worried about how to produce the required verification and validation documents. “What do we do?” they asked us. “We’re not supposed to do documentation in agile.”
That’s a myth. In agile development, the question isn’t whether to document. It’s what kind of documentation to create, and when. Like everything else in agile, those decisions are based on your assessment of value—in this case, the value of the documentation. More documentation is not necessarily better. In fact, the volume of product documentation often is inversely related to its value.
You essentially have two types of documentation: process and product documentation. In either case, we urge teams to focus on the documentation’s consumers and look closely at their usage needs. Look at the documentation from the consumer’s perspective, and explore her usability needs to determine the minimum useful and usable documentation.
Process documentation describes the work-in-progress or handover information the stakeholders produce as they discover and deliver the product—the software application, system, or device containing software. Process documentation has less value for a co-located, domain-savvy team than for a team working in a distributed mode in different time zones and with varying degrees of domain expertise. On the other hand, even a co-located team may need process documentation if they are building a regulated product and require evidence of product verification, as in our client’s case.
Product documentation, which conveys information about the product, is an asset that tends to be valuable because it’s used to sell, service, and use the product. Consider that the consumer of your product documentation might be a validation analyst from a regulatory body, a product end user, an installer, a help desk technician, a field staffer, a maintenance programmer, and so on.
For our medical device client, the product documentation included scripts for a demo used to conduct validated learning to test the product idea itself. We took the perspective of the people going on-site to conduct the demos and, as a result, we created a booklet in a slim, tabular format with abbreviated feature descriptions and demo steps. Not only was this booklet “just enough” to document the product, but it was also fast to produce. As a bonus, the delivery team found the format useful for on-boarding new team members.
On Your Mark…
Teams, including the product owners, need to decide when to produce documentation. There are the two meta-patterns: build it incrementally in small bits as you build the software (and when you have the greatest knowledge for creating the documentation), or defer until prior to release (batching documentation as a larger set, created all at once).
When the requirements are fairly well known, documenting early and often makes sense. On the other hand, our medical device client was essentially a start-up. The potentially lifesaving devices were being used experimentally with patients in the hospital, and the requirements were changing as the product itself was being tested. This meant that it would have been wasteful to document what the team was delivering at each iteration. They agreed to wait to document prior to each release throughout the experimental usage of the product (this is roughly equivalent to what a Lean start-up calls “validated learning”). For this team, it made sense to defer documentation.
A good practice is to produce documentation as part of the acceptance criteria for completing a slice of the product, whether it’s a story, feature, or minimum marketable feature—whatever anchor you use to describe the requirements you’re delivering. When you make the necessary and sufficient documentation a part of the acceptance criteria, you’re gaining value for little added effort.
Sliding Along the Documentation Levers
Consider documentation formality and precision and the volatility of your requirements. Do you need documentation that conforms to a predefined format, sign-off, and so on? Will informal documentation good enough? How precise must the documentation be? Who will be consuming the documentation, and to what end? And as with our medical team, documenting too soon would have been wasteful because of the volatility of the requirements; yet, when it was produced, it needed to be precise and formal.
There is no one size fits all. As shown in Figure 2, different product and project situations influence how you will adapt your documentation plans.
The Low-Down on Documentation
Documentation boils down to knowledge transfer. Where possible, document in chunks, and deliver just enough to serve the needs of the specific consumer of the documentation. In that way, you maximize the value you create for the effort you invest.
Don’t forget to leave your comments below!
Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, Inc., 2012.
In seiner wundervollen Präsentation „Why is Agile failing in large enterprises“ zeigt Mike Cottmeyer, dass drei Grundannahmen dabei helfen, die agile Enterprise zu etablieren:
- Working Hypothesis: Agile transformation begins by defining a rational system of delivery for the enterprise
- Working Hypothesis: True agility is about breaking dependencies across the entire organization
- Working Hypothesis: Healthy culture and effective practices only emerge within a rational delivery framework
Damit man diese Hypothesen umsetzen kann, definiert er dann im Anschluss eine agile Organisation, die im Kern aus Teams auf vier Ebenen besteht:
- Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team.
- Programs Teams – These teams define requirements, set technical direction, and provide context and coordination.
- Portfolio Teams – These teams govern the portfolio and make sure that work is moving through the system.
Ja, ich teile die Behauptung, dass man Service Teams und Product Teams in großen Organisationen unterscheiden sollte. Die Product Teams sind dann die Stakeholder der Service Teams. Je mehr ich darüber nachdenke, werden bei mir aus den “!” aber einige große “?”. Mikes Framework mit Program Teams und Portfolio Teams muss ich entgegenhalten, dass hier eine hierarchische und von oben nach unten tröpfelnde Kette von Inhalten (Anforderungen, Constraints) etabliert wird.
Der beschriebene Ansatz, der auch Kern des Scaled Agile Framework ist, ist auf den ersten Blick erfolgreich. Doch macht er aus sich selbst organisierenden, eigenverantwortlich arbeitenden Teams eine Scrum-Maschine. Scrum-Teams waren anders gemeint: Sie stellen eine Organisation dar, die ähnlich wie eine Verbindung aus Business Units funktioniert. Die agile Organisation so wie beschrieben zu strukturieren, zerstört den Kern von Scrum und Agilität.
Es hat mit dem, was hinter Scrum steckt und mit dem Agile Manifesto einmal definiert wurde, leider nicht mehr viel zu tun. Nonaka, Ken, Jeff und ich – wir gingen davon aus, dass die Product Teams (so wie schon bei Skunk Works und im berühmten Artikel von Nonaka – “The New New Product Development Game” beschrieben) selbständig darüber nachdenken, was sie liefern. Das führt zur Schlussfolgerung, dass die Product Scrum Teams tatsächlich selbst die Anforderungen definieren. Selbständig, weil sie cross-funktional Lösungen für die Probleme der Kunden/User liefern. Die Scrum-Teams schaffen also eigenverantwortlich einen Wert für ein Unternehmen.
Ich verstehe den Impuls, dass man von oben her denken will. Aber Scrum war und ist immer von der Kernidee der eigenverantwortlichen und sich selbst auf das Ziel ausrichtenden, cross-funktionalen Teams getrieben, denen man einen Management-Framework zur Unterstützung gibt.
Skalierung so verstanden lässt den Teams den Raum, sich zu organisieren – sogar wenn es um 300 oder 1000 Teammitglieder gibt. Modelle wie dieses finden sich NICHT in den Büchern der derzeit modernen agilen Coaches, sondern in den Ideen aus der Organisationsentwicklung der letzen 20 Jahre. Es gibt Modelle wie die Open Space Technologie, die viel besser geeignet sind, wirklich große Projekte zu steuern, wie z.B. Harrison Owen schon mehrfach bewiesen hat. Mit diesen Management-Methoden, die man um Scrum herum aufstellen kann, lassen sich große Organisationen steuern – dann sind große SAP-Implementierungen, Data-Warehouse-Entwicklungen, medizintechnische Produkte oder andere Hardware-Entwicklungen genauso einfach mit agilen Methoden umzusetzen, wie es heute schon bei großen Software-Development-Projekten passiert.
Wer darüber mehr wissen will – wir haben ein neues Training dazu: