In our excitement to launch 3.0, we overlooked the staging of a rollback version of the site for people who are still teaching or testing on SAFe 2.5. If this has affected you, we apologize for the trouble and appreciate your patience during the transition. The rollback 2.5 Scaled Agile Framework site is now available at:
This is a snapshot of the site exactly as it was right before we migrated to the new version, so it will support all of your needs for teaching and testing on 2.5. This site, scaledagileframework.com, now features SAFe 3.0.
We appreciate the enthusiasm and feedback we’re getting on the new version of the Framework, and are looking forward to supporting your migration from 2.5 to 3.0.
—Dean Leffingwell, Chief Methodologist
—Alex Yakyma, Associate Methodologist
Diana reminds us how to reclaim our goal of reaching for and achieving our “best jobs ever”, by protecting those practices and attitudes that create them wherever we experienced them in life, in or out of Agile.
How do you make your current team experience the benchmark for all future work? No matter who you are, or where you work – there’s room for more love for work on your team – let’s discover it together!
The post Agile 2014 Keynote Speaker Diana Larsen – Best Job Ever! appeared first on BigVisible Solutions.
Dean Leffingwell stops by the BigVisible booth to talk about the recent updates to the Scaled Agile Framework.
The latest version features extensive refinements to many elements of the methodology infrastructure, as well as new content and guidance that helps enterprises better organize around value delivery, and improve coordination of large value streams.
For more information on the updates check out the Scaled Agile Framework site.
The post Dean Leffingwell Talks About SAFe 3.0 at Agile 2014 appeared first on BigVisible Solutions.
If you’ve always wanted a better way to conduct your ceremonies, workshops, and trainings, you are not alone. Across the industry teams are exhausted by powerpoint knowledge cramming, confused by feel-good fluff, and losing the message the moment they go back to their desks.
But there is a better way. From TED to World Cafe to Pecha Kucha, there is a revolution in the world of event-based learning. In this hands-on workshop, you will learn how to use the START model, an engagement framework extracted from the un-conference trend. You will see that patterns across all these alternative formats, and get real practice applying them to your own meetings and classes.
The post Jessie Fewell on Breakthrough Learning and Engagement at Agile 2014 appeared first on BigVisible Solutions.
Metrics help forecast and manage Agile projects and teams. Used properly, simple statistical techniques add insight and encourage better actions to be taken. Velocity is the general go to metric, but how well it forecasts the future is the elephant in the Agile community’s room. Troy talks about how to capture metrics (other than velocity), how to identify which metrics cause the most impact when changed (carry the most information), and how to use metrics to probabilistically (statistically) forecast a future.
Why Software Moneyball? I call a quantitative approach to software project management, “Software Moneyball.” The book, “Moneyball” describes how the Oakland A’s baseball team used analytics to beat better funded competitors ($40M versus $120M), and transformed the business of baseball. If you compete against better funded rivals, you must outsmart them to succeed and better use of analytics is often the sharpest tool in the toolbox. If baseball Managers can do it, so can you.
The post Troy Magennis – “Software Moneyball ” at Agile 2014 appeared first on BigVisible Solutions.
Dave Prior presented on The Personal Agility Canvas at Agile 2014. Conference attendees were so excited about the talk and the tools presented that we wanted to give everyone the opportunity to learn a little bit more about the topic!
See the session description below as well as the tools presented by Dave – If you are interested in hearing the talk live- Register now for Dave’s repeat performance!
Becoming Agile is never easy and never ending. Each of us who works with teams, and organizations spends a lot of time focusing on how to help others become more Agile. Just as critical though, is the need reflect on how WE can improve our capacity for Agile Servant Leadership because in different ways, each of us is our own greatest champion and worst enemy when it comes to Agile adoption.
This workshop is for intermediate to advanced Agile practitioners who are interested in deepening their understanding of how to do more of the things that already enable them as Agile leaders, and would like to explore the things that are holding them back.
This session will introduce the Five Measures and the Personal Agility Canvas, a tool modeled on the Business Model Canvas that Agile Practitioners can use to:
- Gain a better understanding of the facets impacting the potential for Agility in a work environment
- Set goals for improving individual capacity to become a better Agile Leader
- Identify key areas of focus for improvement
- Establish a plan to achieve the goals that have been set
Participants in this session will be guided through how to use these tool to assess and enhance their own personal agility. We will also spend time on how to facilitate the use of these tools with team members and organizations so that the participants are prepare to introduce this on site once they have returned to work.
Download the Tools Now!
The post The Personal Agility Canvas – by Dave Prior at Agile 2014 appeared first on BigVisible Solutions.
Giora, founder of BigVisible Solutions, stops by for a chat with Dave Prior at Agile 2014. They discuss the evolution of the Agile conferences, the new trends in the industry and where the community is headed!
The post Giora Morein – New Trends and the Evolution of Agile appeared first on BigVisible Solutions.
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.
Alan Dayley makes his way around Monday’s night networking event armed with a selfie stick and a microphone he captures attendees experiences and excitement around Agile 2014!
The post Agile 2014 Day One! Gators, Mermaids, and Alan Dayley Oh My! appeared first on BigVisible Solutions.
Mob Programming is a development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. The Whole Team works together to do almost all the work the team does – including coding, designing, testing, and working with the customer (partner, Product Owner, user, etc). We have expanded the “team” nature of all the work we do, not just the planning, retrospectives, and daily stand-up or other meetings, but all the work that the team does.
Martin talks us through his Agile 2014 presentation.
How do you have coaching conversations with effects that are seen, heard and felt across the board? How do you have all encompassing, inclusive discussions which drive an enterprise towards a truly shared vision?
Agile is part of the answer, but to truly achieve amazing results from the ways we interact with each other, we believe that we also need to unlock the insight, wisdom and energy held captive within our teams and organizations. We have created a key, and we call it ‘The Lens’. It’s an engineered environment orientated around dialogue, transparency and co-creation, fostered through a combination of physical narrative and engineered experience for everyone from C-level executive to C# programmer and beyond.
The post Martin Kearns Talks Through ‘The Lens’ at Agile 2014 appeared first on BigVisible Solutions.
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:
I updated my Motivational Quotes page.
I’ve got more than 100 motivational quotes on the page to help you find your inner-fire.
It’s not your ordinary motivational quotes list.
It’s deep and it draws from several masters of inspiration including Bruce Lee, Jim Rohn, and Zig Ziglar.
Here is a sampling of some of my personal favorite motivational quotes ..
“If you always put limit on everything you do, physical or anything else. It will spread into your work and into your life. There are no limits. There are only plateaus, and you must not stay there, you must go beyond them.” – Bruce Lee
“Knowing is not enough; we must apply. Willing is not enough; we must do.” - Johann Wolfgang von Goethe
“Kites rise highest against the wind; not with it.” – Winston Churchill
“To hell with circumstances; I create opportunities.” – Bruce Lee
“Our greatest glory is not in never falling but in rising every time we fall.” – Confucius
“There is no such thing as failure. There are only results.” – Tony Robbins
“When it’s time to die, let us not discover that we have never lived.” -Henry David Thoreau
“People who say it cannot be done should not interrupt those who are doing it.” – Anonymous
“Motivation alone is not enough. If you have an idiot and you motivate him, now you have a motivated idiot.” – Jim Rohn
“If you love life, don’t waste time, for time is what life is made up of.” – Bruce Lee
For more quotes, check out my motivational quotes page.
It’s a living page and at some point I’ll do a complete revamp.
I think in the future I’ll organize it by sub-categories within motivation rather than by people.I think at the time it made sense to have words of wisdom by various folks, but now I think grouping motivational quotes by sub-categories would work much better, especially when there is such a large quantity of quotes.
For those interested in learning more about Teaching Kids Programming, visit their site - http://teachingkidsprogramming.org This is AWESOME!
The post Llewlyn Falco – Teaching Kids Programming – at Agile 2014 appeared first on BigVisible Solutions.
Well, one must follow the news to make sense of that gibberish... and the 1984 reference.... it goes back to the famous Superbowl Apple commercial introducing the Mac.
An IBM/Apple partnership to tunnel into the enterprise walled garden for devices is a great idea. As a consumer it works for me. I don't know of any enterprises that can pass the Starbucks Test (test for the ubiquity of access for the digital native).
In 2005 (years before the iPhone) Apple joined forces with Motorola to launch the ROKR, a cell phone and iTunes connected music player.
"Jointly developed with Motorola and made available on what was then the Cingular Wireless network, the iTunes-savvy Motorola ROKR may have been fugly, but Apple engineers learned as much as they could while developing it: lessons which helped them avoid the same mistakes in the iPhone..." -- Jonny Evans
The ROKR was a great "beta" success for one of the partners (Apple) and a market failure for the other. The device was both a phone and a 100-song music player with iTunes integration. I bought one for my wife and she didn't love it. I (the geek in the family) found it intriguingly interesting but frustratingly difficult to manage the songs and syncing.
It was not the disruptive innovation that would come two years later. For $250 and a two-year contract you got a 1.7 inch color display, stereo speakers, camera/video recorder and a phone with a few built in "apps". What did Apple learn from the introduction of this device and the partnership with the leading mobile device maker? One thing they learned was that without full control over the product it would be ugly! It was not innovative - just an incremental mashup of the walkman with the cell-phone. Jobs was after revolution. Hence the 100-song limit on the ROKR. The iPhone launch was only 17 months away in January 2007. Of course Apple would want to cripple the device, yet slip their toes into the waters. What a great beta test with real users and all-out marketing to see how the US would react. The product launch and validated learning was quite beneficial to Apple, not so much for Motorola.
Will the IBM-Apple partnership prove beneficial to both? Some pundits feel it is an indication of weakness in Tim Cook's leadership and that it is signaling a lack of innovation at Apple.
The deal according to the Wall Street Journal has IBM developing 100 iOS apps and supporting the business customers using those apps and products.
IBM will sell iPhones and iPads to its enterprises clients. Putting thousands of IBM consultants peddling the new Apple mobile app development language Swift. Along with apps that manage your enterprise. The answer to everyones Jeopardy question... will Siri go out with Watson?
So what will be the outcome of this partnership - will it benefit both companies - will it crack open then enterprise to mobile devices? All very good questions that we should be able to answer in two years or so.
Ron and Chet discuss their conference Q/A session experience, thoughts on the best sessions so far at Agile 2014, refactoring issues, Scaling Agile, and so much more!
The post Get Real with Ron Jeffries and Chet Hendrickson at Agile 2014 appeared first on BigVisible Solutions.
Brian and Erin talk with Dave Prior at Agile 2014 about how to leverage different types of influences to drive different outcomes or goals. They explore an array of influence and change strategies beyond the traditional top down models of influence by dictate.
The post Brian Bozzuto and Erin Beierwaltes talk Influence Strategy at Agile 2014 appeared first on BigVisible Solutions.