It is good practice to first write large user stories (commonly known as epics) and then to split them into smaller pieces, a process known as product backlog refinement or grooming. When product backlog items are split, they are often re-estimated.
I’m often asked if the sum of the estimates on the smaller stories must equal the estimate on the original, larger story.
Part of the reason for splitting the stories is to understand them better. Team members discuss the story with the product owner. As a product owner clarifies a user story, the team will know more about the work they are to do.
That improved knowledge should be reflected in any estimates they provide. If those estimates don’t sum to the same value as the original story, so be it.But What About the Burndown?
But, I hear you asking, what about the release burndown chart? A boss, client or customer was told that a story was equal to 20 points. Now that the team split it apart, it’s become bigger.
Well, first, and I always feel compelled to say this: We should always stress to our bosses, clients and customers that estimates are estimates and not commitments.
When we told them the story would be 20 points, that meant perhaps 20, perhaps 15, perhaps 25. Perhaps even 10 or 40 if things went particularly well or poorly.
OK, you’ve probably delivered that message, and it may have gone in one ear and out the other of your boss, client or customer. So here’s something else you should be doing that can protect you against a story becoming larger when split and its parts are re-estimated.
I’ve always written and trained that the numbers in Planning Poker are best thought of as buckets of water.
You have, for example an 8 and a 13 but not a 10 card. If you have a story that you think is a 10, you need to estimate it as a 13. This slight rounding up (which only occurs on medium to large numbers) will mitigate the effect of stories becoming larger when split.
Consider the example of a story a team thinks is a 15. If they play Planning Poker the way I recommend, they will call that large story a 20.
Later, they split it into multiple smaller stories. Let’s say they split it into stories they estimate as 8, 8 and 5. That’s 21. That’s significantly larger than the 15 they really thought it was, but not much larger at all than the 20 they put on the story.
In practice, I’ve found this slight pessimistic bias to work well to counter the natural tendency I believe many developers have to underestimate, and to provide a balance against those who will be overly shocked when any actual overruns its estimate.
Agile2015 is just a week away. I will be presenting my talk on Product Owner Teams: Leading Agile Program Management and want to share some thoughts ahead of time on the problem we are solving with the PO Team.
I summarize the Goals in a couple of bullet points:
- Provide Agile Teams with the support, guidance and coaching they need to get the job done
- Improve and accelerate your product delivery by improving your Agile Transformation
I focus the talk on four key Objectives:
- Provide clarity through a well defined feature backlog
- Hold Agile Teams accountable for making and meeting commitments
- Demonstrate measurable progress by facilitating the demonstration of integrated features
- Provide timely information to Portfolio Management for investment decisions
Here’s more detail from the abstract for my talk:
“Building a clear and effective product backlog to deliver on strategic initiatives in an enterprise attempting agile can be difficult. Now add the competing needs of other work with various stakeholders across the organization. And that’s not the hardest part. The real challenge is prioritizing and coordinating considering risks, technical viability and planning dependencies.
The Product Owner Team wrestles with these organizational challenges to provide Agile Teams with the support they need to get the job done. This team ensures the work is strategically aligned and prioritized with Portfolio Management. Only then can the team establish, maintain and coordinate a clear feature backlog for Agile Teams in a complex environment.
The Product Owner Team will improve and accelerate an organization’s agile transformation. This talk presents a proven framework for leading Agile Program Management including the roles, artifacts and activities for an effective Product Owner Team. Additionally, this talk introduces an Agile Program Management starter kit so participants can get started quickly in their own organization.”
The work of the PO Team is challenging. It requires motivated individuals with a clear plan. I hope to help by providing a starting place for the plan.
DevOps Software Development is new to many organizations and figuring out how to best collaborate can be challenging. One of the recurring roadblocks experienced by the organizations we serve revolves around collaboration. What are some of the difficulties they face and how can DevOps address these to help deliver great software and build systems that scale and last?
At Blue Agility, we have been leading large-scale agile transformations to help our clients align business and IT, achieve faster time-to-market, and remain competitive in the current marketplace.
DevOps Software Development
Software development is an intense collaborative process where success depends on the ability to create, share and integrate information at a very rapid pace. With globalization comes a growing need to foster highly productive software development teams that can operate successfully in this global market. Distance creates an additional challenge to development processes, as fewer opportunities exist for rich interaction and direct communication occurs less frequently.
Virtual team collaboration is the collaboration of teams that are not located in the same physical location. These teams could be either on-site, near-shore, offshore or a combination of the three types.
Whether dealing with teams collaborating in the same location or virtual teams across multiple locations, collaboration is key to a successful DevOps transformation.
DevOps is focused on improving the principles of collaboration including:
Voice of the Customer
Just in Time Requirements
How to Collaborate
So how is collaboration best optimized within DevOps?
The key is to enable effective collaboration at the three following layers:
Team Collaboration: DevOps builds on the concept of small teams working together to achieve “great things.”
Team of Teams Collaboration: A group of teams working in cadence and synchronizing often.
Intent/Idea Collaboration: Alignment to ideas/concepts that have been identified, analyzed and approved for delivery.
With the challenges of collaboration, tooling to support the development teams becomes critical. Whichever tool is selected, it must have the ability to deliver transparent and effective collaboration for all three layers to truly be successful across the entire delivery life cycle.
Ultimately, the improved collaboration afforded by DevOps Software Development leads to better reliability, more time to focus on the core business, faster time to market, and of course, happier clients.
It’s not unusual for a developer to change jobs every two or three years or even more often. Up until 2004 I had never thought of a company keeping up with you after you left or having an ‘Alumni’ concept. The consulting outfit I left had instituted an alumni program and sent me out a tiny flash stick with the company logo on it about a year after I left. It was a small thing, but I was kind of impressed they bothered with any effort at all. In addition they sent out an email every month or so with an update on how their business was going. About 6 years later I ended up back at the same company, partially because they had maintained a good relationship with me, and realized I left not so much because of them, but more for an opportunity to manage a development teams.
I came across this practice again in the most recent episode of The Front Side Podcast where they explained they were trying to build the company culture that allowed you to just tell your manager you were going on an interview. This is exactly the sort of thing to get you escorted out in many big companies, but they seem to be experimenting with having a very open and honest culture that admits, especially in consulting that many of your developers will leave at some point sometimes even over to your clients. They wanted an environment where a developer could admit they wanted a new experience the consulting business couldn’t provide and they left the door open down the road as Alumni to welcome them back.
I think it’s a great experiment and I’m honestly impressed if they can produce a company culture where an employee feels safe admitting they’re going on an interview. I love that companies are experimenting and blogging/podcasting on how it’s going. I also think the alumni idea is a great way to keep people motivated and maintain a good relationship with your local development community. I know some of the best recruiters I had were former employees who could explain why they left the company, but how it was a great opportunity if you were a good fit.
Nextgov: How do you define transparency?
Fung: My definition is quite a bit different from the conventional wisdom about transparency. A transparency system is designed to allow people to improve the quality of decisions they make in some way, shape or form, and it enables them to improve their decisions to reduce the risks they face or to protect their interests. Some of those decisions are about political accountability but some are in private life, like what food to buy or what doctor to go to.-- Archon Fung, professor at Harvard University's John F. Kennedy School of Government who studies government transparency.
Does your company practice fair pay? Here's what one worker brought to Google and made a difference in transparency at the search giant.
Tell Your Co-Workers How Much You Make! There's no law against it and it increases the chances you'll be paid fairly.
Does the Agile Manifesto imply some form of organizational transparency? I believe so, yes. Here's what Jeff Sutherland has to say about the topic, look for the Individual and Interaction section. Agile Principles and Values by Jeff Sutherland on MSDN.
Scrum's 5 core values list the concept of Openness. Is this not very similar to Transparency?
There are lots of synonyms - visibility, openness, observable, apparent, etc.
Does this value of transparency imply that the information flows in both directions, up and down an organizational hierarchy, from line-workers to managers & directors, as well as from CEO to directors and wage earners also?
Elements of an Effective BacklogGood Journalism is Transparent and Objective by John Zhu
In an agile transformation, one of the first things we work towards is to create an ability to deliver in a predictable manner. As described in our compass and our journey, there is a clear path for organizations that embark on an agile transformation. By becoming predictable, an organization can make and keep promises. In essence, we are working to stabilize the value delivery system.
There are many things that can contribute to an unstable value delivery system. Ready backlog is one of these. The following diagram illustrates three fundamental elements of agile.
Clarity means that we have a system in which the work we’re asking delivery teams to deliver is clear and well understood. Structure means we have created cross-functional teams that have everything necessary to create an increment of working tested software. The ability to see working tested code is how we demonstrate measurable progress.
Our goal is to provide backlogs that are well understood by delivery teams. When we have ready backlog, delivery teams are able to make and meet their commitments. One contributor of instability is that the backlog items are not truly ready but the team chooses to pull them into a sprint anyway. Unready work creates churn for the delivery team, they spend more time trying to figure out what they are supposed to do than actually doing work to deliver. They may guess and build based on their understanding which may be, and often is, flawed.The Definition of Ready
How do we know the backlog items are ready? Through a definition of ready. Most people are familiar with the term “definition of done”, but many organizations I’ve worked with are not as familiar with the definition of ready.
Just as a definition of done is used to create alignment across a delivery team on what it means to be done with a backlog item, the definition of ready provides clarity to a product owner or product owner team on what it means to create ready backlog items. What might be in a definition of ready? This varies but a list of potential items are in the following list:
- All stories must meet the INVEST criteria
- A clearly defined user
- Story has been estimated
- Acceptance criteria with examples
- Acceptance criteria in a certain format such as “given…, when…, then…”
- External information that can provide context such as:
- User journeys that provide context for the backlog item
- Screen mockups
- Architectural drawings
- Business rules
The definition of ready will be specific to an organization and may even vary across the organization. The definition of ready may need to be more inclusive when working with teams that have little domain knowledge. Maybe it is lighter for teams that have deep product knowledge and a long working relationship with the product owner. The real test is to make sure the backlog items have enough clarity so that the delivery teams are able to make a commitment for delivering items within a sprint.
The definition of ready can evolve over time and is a good mechanism to instill new behaviors. Maybe UI mock ups are something that isn’t normally provided but a delivery team believes this is something that is needed. Add it to the definition of ready. If at some point this is just the way work is done, that new behavior now exists, then remove it. Up to you, just make sure it creates clarity on what is expected.
Having clarity in the backlog is a critical element of a value delivery system. It certainly isn’t the only thing that is needed but we find that backlog clarity is necessary for creating a predictable delivery system. Give it a try if you don’t have one and see if it helps.
By the way, here is a job aid that might be useful for crafting your definition of ready. This job aid is designed to provide guidance on how to create clear user stories.
After a period of working too hard, I have been able to attend a few user group meetings this year. A couple of patterns have stood out for me. Patterns that don't feel right, but maybe I am exaggerating? Do you recognise any of these?
- The user group is associated with an agile consultancy.
- The user group event starts with some promotion of said consultancy.
- The user group doesn't have a website or even a meet-up page.
- The user group website is mostly promoting high-value courses.
- Membership is free (just sign up for our mailing list).
- The user group event is mostly attended by beginners
- The only really experienced Agilist present is the group's host.
- The user group events are mostly talks by managers, coaches or trainers (in other words, they are a form of self-promotion).
Ah, plans… They say luck favors the prepared. Axosoft Version 15.3 adds to those prepping efforts. The Release Planner introduces a new way to approach resource allocation for your sprints and releases. Here’s my voice describing the planner with visual detail:Release Planner
To start this tour, click the Release Planner tab; the planner will appear on the right and your items will be in the workspace on the left.Workspace on the left. Release Planner on the right.
The workspace will be filtered by your Organize Panel selection along with any additional filters, grouping, or sorting you have enabled. Use this customization to get a view of all the items up for consideration.
Over on the planner side, select the release from the dropdown menu or create a new release. This section of the Release Planner allows you to:
- Adjust the start date and due date
- Edit your release details
- Add teams or users participating in this release
- Expand or collapse the users and teams
Your release selection will display all the items currently assigned to each of your teams and team members, as well as any unassigned items in the release/sprint. Each team member will have their own section with:
- Number of items assigned to them
- Amount of time already assigned
- Any available capacity
Any items not assigned to anyone will be located under the [Unassigned ] section and you can remove users by clicking the X symbol to remove that team or user. Removing users will leave their items in the release under [Unassigned]. You can also drag items from the left and drop them in above the user/teams to add them to the release. Any items that are already assigned will add that user to the release. You can also reassign items to a different user from within the planner.Drag and drop items to allocate work. Watch the capacities update How do I set user capacity?
Editing a team member’s settings will allow you to set that user’s work days, daily capacity, and vacation days. Any user of the system can update this themselves by navigating to their username in the upper right and then selecting User Options > Capacity.
User capacities roll up to the release capacity you see in the upper right. This visually shows you:
- Total hours assigned to individual users
- Total hours assigned to teams
- Hours left unassigned
- Remaining available capacity
With this knowledge, drag and drop the items from the workspace on the left to the appropriate user or team on the right and watch your release capacity update. If you exceed your capacity, you should get a red warning so that you can adjust accordingly.
Keep in mind, the capacity you define in the release settings will supersede the user capacities that roll up from all your individual users and teams. You are welcome to use just the user capacities or both!One More Update
One last thing, the Daily Scrum has been renamed to “Standup.” Easy enough, right?Daily Scrum is now Standup
Normally these workshops start with the leadership (the stakeholders or shareholders) which have a vision for a product (or project). This time we skipped this activity.
The purpose of the Workshop is to ensure alignment between the leadership team and the Agile Coaches with regards to the upcoming scrum workshop for the team(s). Set expectations for a transition from current (ad-hoc) practices to Scrum. Explain and educate on the role of the Product Owner.
- Create a transition plan/schedule
- Set realistic expectations for transition and next release
- Overview of Scrum & leadership in an Agile environment
- Identify a Scrum Product Owner – review role expectations
- Alignment on Project/Program purpose or vision
- Release goal (within context of Project/Program & Scrum transition)
Once we have alignment on the Product Owner role and the Project Vision we typically do a second workshop for the PO to elaborate the Product Vision into a Backlog. This time we skipped this activity.
The purpose of the Workshop is to educate the Product Owner (one person) and prepare a product backlog for the scrum immersion workshop. Also include the various consultants, SME, BA, developers, etc. in the backlog grooming process. Expected Outcomes:
- Set realistic expectations for transition and next release
- Overview of Scrum & Product Owner role (and how the team supports this role)
- Set PO role responsibilities and expectations
- Alignment of Release goal (within context of Project/Program & Scrum transition)
- Product Backlog ordered (prioritized) for the first 2 sprints
- Agreement to Scrum cadence for planning meetings and grooming backlog and sprint review meetings
Once we have a PO engaged and we have a Product Backlog it is time to launch the team with a workshop - this activity typically requires from 2 to 5 days. This is the activity we did at GameStop this week.
The primary purpose of the workshop is to teach just enough of the Scrum process framework and the Agile mindset to get the team functioning as a Scrum team and working on the product backlog immediately after the workshop ends (begin Sprint One). Expected Outcomes:
- Set realistic expectations for transition and next release
- Basic mechanics of Scrum process framework
- Understanding of additional engineering practices required to be an effective Scrum team A groomed / refined product backlog for 1- 3 iterations
- A backlog that is estimated for 1 – 3 iterations
- A Release plan, and expectations of its fidelity – plans to re-plan
- Ability to start the very next day with Sprint Planning
Images from the workshop
The team brainstormed and the prioritized the objectives and activities of the workshop.
Purpose and Objectives of the WorkshopThe team then prioritized the Meta backlog (a list of both work items and learning items and activities) for the workshop.
Meta Backlog of workshop teams - ordered by participants
Possible PBI for Next Meta Sprint
Possible PBI for Later Sprints
Possible PBI for Some Day
Possible PBI for Another Month or Never
A few examples of work products (outcomes) from the workshop.
Affinity grouping of Persona for the user role in stories
Project Success Sliders activityTeam Roster (# of teams person is on)
A few team members working hardThree stories written during elaboration activity
A few stories after Affinity Estimation
Release Planning: Using the concept of deriving duration based upon the estimated effort. We made some assumptions of the business desired outcome; that was to finish the complete product backlog by a fixed date.
The 1st iteration of a Release Plan That didn't feel good to the team, so we tried a different approach. To fix the scope and cost, but to have a variable timeframe.
The 2nd iteration of a Release Plan That didn't feel good to the PO, so we tried again. This time we fixed the cost and time, but varied the features, and broke the product backlog into milestones of releasable, valuable software.
The 3rd iteration of a Release PlanThis initial release plan feels better to both the team and the PO, so we start here. Ready for sprint planning tomorrow.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Ever heard these from teams before regarding timeboxing?
- “What we do won’t fit into a 2 week window”
- “The nature of our work is too creative for a timebox”
- <<<Fill in your variation here>>>
If you work with agile teams, some variation of these statements will be familiar. I consistently hear new teams say this over and over when I form new sets of teams.
Here’s the deal, the problem is not the time box. In fact, the time box is exposing problems you need to solve!
Let’s check out some examples of the team’s timeboxing complaints above.
“What we do won’t fit into a 2 week window”
An example team that could have this problem is a one that is siloed by discipline. I am currently working with a set of agile data teams that fit this mold. The team members are very much specialists.
- Data Architecture via Modeling and Data Flows
- Data Analysis
- Coding in Scala and Java
- Data Analytics
- Data Warehousing
- Stored Procedures
- Testing and Automation
- And probably a few more things that I don’t even know about
In total these capabilities make up a cross-functional team. Inside that team they typically do these tasks in sequence waiting for each other to finish. It’s no wonder they can’t fit anything into a sprint!
To fix this
This team is finding ways to work in parallel. This feels a lot like design by contract for each of these sequential items.
To make this even faster
The team will generalize a bit more to swarm around work that can’t be broken into the design by contract method.
Swarming will require team members learn how to maintain their specialty while learning how to help out with another capability needed by the team. That doesn’t mean be a specialist in both, keep your sanity. So, “If I know ETL, can I learn to help with Data Analysis or Stored Procedures?”
Let’s take a look at another common one.
“The nature of our work is too creative for the time box”
Regarding creatives… there is a large belief that most every discipline in product development is creative by that discipline.
We all see ourselves that way. There is a natural tendency to want to go somewhere, be creative, and come back with our creation. However, the importance of feedback is never more apparent than in truly creative environments.
Let’s consider a company creating it’s brand identity. The brand is going to have a significant impact on how customers pick and choose the company or a competitor. Even in this environment, we don’t want to have a team go away and comeback with some gold-plated logo that misses the mark after 3 months.
To fix this
Instead we want to see steady progress toward success. By keeping the actual creative property transparent while collaborating around it, we can maintain visibility of the value that is being created and decide when enough is good enough.
Multiple creatives will be taken into the timebox because no one likes to commit to one thing and have it miss after two weeks. That’s too much risk, so they break it down into smaller deliverables. This benefits the “creative” and the customer.
To wrap up
Timeboxing is not the problem. Timeboxing exposes problems and encourages innovation to find new solutions. From our sprints to daily commitments and on to release planning you will find timeboxes everywhere in agile systems. If you use something like the pomodoro technique, it’s in most every part of your day. This is a critical part for teams to realize as a benefit, not a problem.
Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features.
This is the same problem as ranking for the project portfolio. You can apply similar thinking.
Once you have a roadmap, use these tips to help you rank the features in the backlog:
- Should you do this feature at all? I normally ask this question about small features, not epics. However, you can start with the epic (or theme) and apply this question there. Especially if you ask, “Should we do this epic for this release?”
Use Business Value Points to see the relative importance of a feature. Assign each feature/story a unique value. If you do this with the team, you can explain why you rank this feature in this way. The discussion is what’s most valuable about this.
Use Cost of Delay to understand the delay that not having this feature would incur for the release.
Who has Waste from not having this feature? Who cannot do their work, or has a workaround because this feature is not done yet?
Who is waiting for this feature? Is it a specific customer, or all customers, or someone else?
Pair-wise and other comparison methods work. You can use single or double elimination as a way to say, “Let’s do this one now and that feature later.”
What is the risk of doing this feature or not doing this feature?
Don Reinertsen advocates doing the Weighted Shortest Job first. That requires knowing the cost of delay for the work and the estimated duration of the work. If you keep your stories small, you might have a good estimate. If not, you might not know what the weighted shortest job is.
And, if you keep your stories small, you can just use the cost of delay.
Jason Yip wrote Problems I have with SAFe-style WSJF, which is a great primer on Weighted Shortest Job First.
I’ll be helping product owners work through how to value their backlogs in Product Owner Training for Your Agency, starting in August. When you are not inside the organization, but supplying services to the organization, these decisions can be even more difficult to make. Want to join us?
While the DevOps culture has been heavy focused on what tools to use, little thought has been giving to what type of workspaces is needed. Ever since the early days of agile, the importance of an informative workspace has been known. Many of the practices around working together, pair programming and the Onsite Customer from Extreme Programming were to enable the rapid flow and visualization of how the team is doing. Other aspects, such as the Big Visual Chart, were included to keep the information flowing. We have made great progress in this category, but we still have more to do.
Now, fast forward to the DevOps Culture. Much like the original agile movement, DevOps is a relatively unique change in the world of work that involves both cultural and technical shifts. It’s just not enough to have cool new tools like Puppet and Chef, or any of the other cool tools that make continuous delivery “a thing.” We need to be able to think about how we are planning our stories. We need to be able to be including acceptance criteria that go beyond just “is it done,” but also all the way to “is it staying done?”
We often run into this as agile consultants. I have often gone to work with a client and their number one concern as we are going through the engagement is “ok, and what do we do on day one of the sprint when we don’t have you here coaching us?” Now, they are fine on their own, but part of the plan is to know what to do after the training wheels are off. Let’s look at that same idea in terms of DevOps Culture. Stories have a very limited life. Once the product owner has accepted the story, we tear it up and throw it away, metaphorically speaking. But that isn’t the end of the story. The software now needs to live and breathe in the big wide world. How do we do that? DevOps is of course the answer, but what exactly does that mean?
Workspaces in the DevOps Culture
As mentioned earlier in this article, the idea of an informed workspace is a valuable tool in our belt for moving deeper and wider into the DevOps culture. Think back to one of the biggest cultural changes called for in the early adoption of agile. Agile called for bringing QA into the room. We aren’t treating QA as a separate team, but part of the team. All of a sudden we are paying close attention to the number of tests that are passing. So now part of our Big Visual Chart is focused on the pass/fail rate of our tests, not just the status of the story itself. This shift took a lot of effort, and I think that if we are honest with ourselves it’s not done yet. But that is an article for another time. We want to take a deeper look at the keys to successfully affecting a further transformation to the DevOps culture. What aspects will really help us do more than just have lots of automated builds that we call done, with no thought to what happens after?
The first step is to think about the cultural changes required. What is it that we will need to change in our thinking in order to make DevOps more than just another buzzword at our shop? The first, and hardest, change is to stop thinking in terms of the “DevOps team”. The whole team is part of Dev and Ops. There just is no wall to throw “finished” product over anymore. It’s all about creating great and long lasting software. There are many steps that we have already taken to get there, but this is one of the biggest. So let’s take a look at the different activities that really make a DevOps culture thrive.
Of course, the first thing one thinks about when discussing DevOps is the activities that support continuous delivery. This means an even higher need for all tests to be automated. Unit tests are merely the start, followed closely by automating your acceptance tests. Having these tests running continuously throughout the day is basically the cost of entry into the DevOps culture. Without a strong continuous integration server, running tests all day and every day, we just can’t be sure that what we are releasing is of a high enough quality to stay healthy in the real world. After that, the art of continuous deployment becomes an additional challenge. Orchestration tools are vital to make sure the right bits get bundled with the other right bits, and then get put where they belong. And then, since we are all part of “keeping the lights on,” we need monitoring tools to help us visualize whether our software really is behaving properly. So yes, there is a definite technical aspect to DevOps.
That’s a lot of moving parts! We need to keep track of where we are. This leads to one of the cool parts of a true DevOps implementation. All those cool monitors that the Ops guys get with the fancy graphs and uptime charts? They come into the room with the Ops people. And we need to add to them. We are going to track story progress from idea to implementation, and then into the wild. My acceptance criteria are going to include things like “must have Nagios hooks” and “will use less then x% of CPU”. And now we have to live up to it. This means it is more important than ever to be able to visualize the entire flow. Our Big Visual Charts need to be able to show us not just how the current iteration is going. They must show us the state of the build server, the state of the various builds and where they are in any of the extended process, such as UAT, etc. And, in the unlikely event of a failure anywhere along the line, or in post-production, we can follow a clear chain of events back to find the problem quickly.
So now we see that, while DevOps is primarily a people problem, there are a lot of technical aspects that enable a strong DevOps culture. The key to success is the union of the people and technical aspects, which in a way make DevOps a Cyborg. In order to balance these two aspects, and in order to keep ourselves from burning countless hours and countless brain cells chasing down all of the moving parts, we need to focus on Information. The more Information that we can have at our fingertips, the more effective we will be. Each team will identify which information is the most meaningful to them, and how best to interpret it. You can bet that this will be in live charts rather than stale reports. Being able to orchestrate the entire flow of a story’s life, from inception to realization to retirement will be much easier if we can visualize each step of the way. If this means our team room might start looking like the command center in war games, what’s so bad about that?
About the Author
Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]