Watch the Axosoft Best Practices webinar above to learn how to use Axosoft most effectively. We’ve only outlined some of the best practices below.
Daily Usage Best Practices
- Keyboard Shortcuts [shift + ?]
- Create a new item [c]
- Create a new subitem [n then s]
- Add a work log to an item [w]
- Add the projects you work on most to Favorites by right clicking on the project and selecting Add To Favorites
- To assign items, the Assign To field is no longer a static dropdown, you can just start typing and quickly select the user or team’s name/gravatar when it appears
- Quickly delete items by right clicking on the item and selecting Delete
- Quickly copy the URL for an item by right clicking on the item and selecting Copy Item URL (choose whether you want the URL for the web item or the portal item)
- Add a work log by right clicking on the item and selecting Add Worklog
- Add a subitem by right clicking on the item and selecting Add Subitem
- Copy an item to a bug in Axosoft Bug Tracker, by right clicking on the item and selecting Copy to Bug. We recommend copying items rather than moving them.
- If you delete one of your workspace tabs, Click the funnel symbol below the Daily Scrum button and select the tab you want to reopen
- If you accidentally delete an item, use the Audit Trails tab to find the item and copy the details into a new item
- The All Items tab shows you the combined items from all of your other tabs (I.E. Scrum, Bug Tracker and Help Desk items)
- If you have Axosoft Scrum, you can always create an additional Custom Items tab by clicking Tools > System Options > General > checking the Custom Items box > clicking System Labels > and relabeling Custom Items to whatever you’re using it for (I.E. tasks or test cases)
Grouping, Filters and Views
- To what everyone on your team is working on, you can group items by the user they’re assigned to. Click the gear icon in the upper right corner > Group By > User Story > Assigned To
- To group by project, click the gear icon in the upper right corner > Group By > Project
- To add a filter, click the Filters button at the top > Add Filter > name it > click the plus sign to add your filter conditions
- If you’ve applied different groupings and filters to your workspace and want to easily get back to that view, save it as view. To do this, click View > Save View > name your view > check any settings you want saved
- To share a view with other team members, click View > Manage View > deselect Private
- Customers can group items by their status, in the Customer Portal. Click the gear icon in the upper right corner > Group By > Status
- You can create a default view that customers see when they enter your Customer Portal. Click on a user whose view settings you want to use as a default for all your customers. Click on Tools in the upper right corner > Customer Portal > Customer Portal Settings > Security & Customer Defaults > Make sure that user is selected under “Use the selected customer contact’s current view settings” > Save
Custom Item Tab and Related Items
- You can create an additional tab for test cases or any other item type, by clicking on the funnel icon in the upper right corner > Custom Items
- You can connect your test case items back to a defect or another item. Expand the Details panel by clicking the arrow in the top right corner > click Related Items to open that panel > to enable related items for the first time, click Tools then System Options then Details Panel then check the boxes for Related Items and Save > click Add under Related Items > select is related to” in the dropdown menu > Search for Related Item > select Bugs > search for the item number > check the the item > Select > Save
- You can doc Related Items or any pane under the Details panel, to the bottom of your screen to see those details. Just click the arrow on the right corner of the Related Items pane.
- Read more information on test case management, the custom item tab and related items in Axosoft
Um ihren Produktentstehungsprozess planbar zu machen, setzen viele Unternehmen eine Form von Meilensteinplanung ein. Im Detail gibt es hier viele Unterschiede, aber das Prinzip ist immer das gleiche: Die Meilensteine sind Punkte entlang einer zeitlichen Achse, zu denen das Entwicklungsprojekt intern evaluiert wird. Die Zeiträume zwischen den Meilensteinen bilden häufig die Entwicklungsphasen nach dem V-Modell ab. In solchen Fällen folgt auf eine Machbarkeitsstudie die Konzeptionsphase, gefolgt von Design-, Verifikations- und Validationsphasen. Um einen Meilenstein zu “passieren”, wird anhand von festgelegten Dokumenten und Reviews überprüft, ob die vorangehende Phase erfolgreich abgeschlossen wurde.
Zugleich entscheiden sich immer mehr produktentwickelnde Unternehmen (längst nicht mehr nur in der Softwareentwicklung) für den Einsatz agiler Rahmenwerke wie Scrum. Hier kommt dann sehr schnell die Frage auf, ob und wie Scrum mit einer Planung in Meilensteinen “vereinbar” sei oder zumindest “kompatibel” gemacht werden könne. Aus meiner Erfahrung beruht allein schon diese Wortwahl auf der falschen Vorstellung, dass Scrum und Meilensteine zwei Prozessvarianten seien. Wenn das so wäre, müsste man sich für eines von beidem entscheiden – oder eben einen Kompromiss finden, der ein wenig von dem einen und ein wenig von dem anderen realisiert (was auch immer das dann konkret bedeutet).
Scrum ist eine Methode. Scrum sagt, dass Produkte iterativ (in regelmäßig wiederkehrenden Sprints) und inkrementell (Feature für Feature) entwickelt werden, damit die Organisation nicht erst zum Ende des Projektes, sondern kontinuierlich lieferfähig ist. Meilensteinpläne schreiben vor, welche Dokumentation wann im Laufe eines Projektes erzeugt und freigegeben werden muss. Scrum ist darauf ausgerichtet, die Entwicklung am Bedarf des Marktes auszurichten. Meilensteine sind hingegen interne Revisionsmechanismen, um Projekte auf der Spur zu halten.
In meinem aktuellen Projekt sind wir zum Start folgendermaßen vorgegangen:
- Zunächst sind wir die Bausteine der Meilensteinplanung einzeln durchgegangen und haben uns jeweils gefragt, ob diese für eine erfolgreiche Produktlieferung zwingend erforderlich sind.
- Jene Bausteine, die für eine erfolgreiche Produktlieferung zwingend erforderlich sind (z.B. Risikoanalyse, Produktvalidierung, Test der elektromagnetischen Verträglichkeit – EMV), kommen in unsere Definition of Done. Darin klären wir, auf welcher Ebene (Story, Sprint, Release) wir sie einhalten können und wen wir dafür wann heranziehen müssen (z.B. QA beim Schreiben von Testfällen in der Sprintplanung).
- Das hat in der Regel zur Konsequenz, dass die erforderlichen Bausteine deutlich früher geliefert werden, als sie nach der Planung in Meilensteinen gefordert wären.
- Die Bausteine, die für eine erfolgreiche Produktlieferung nicht zwingend erforderlich sind (z.B. Erstellung Lasten- und Pflichtenheft), lassen wir außen vor und betrachten sie nicht weiter.
Zusammenfassend: Es wäre naiv, Meilensteinpläne komplett zu ignorieren. Manche der dort vorgeschriebenen Deliverables sind sehr wohl für eine erfolgreiche Produktlieferung wesentlich. Genauso naiv aber wäre es, die Vorschriften 1:1 umzusetzen, nur weil es der Plan so besagt. Vor allem bietet Scrum die Chance, die starre Abarbeitung von Meilensteinen dadurch überflüssig zu machen, indem die kritischen Projektaspekte schon zu Beginn angegangen werden, so dass der Zweck der Meilensteinplanung – die Projektabsicherung – ohnehin erfüllt wird.
I gave a talk at the global Scrum Gathering in Berlin and two weeks later this revised (and improved?) version at the regional Scrum Gathering in Cape Town.
Scaling agility in any organisation requires attention to both cultural and structural dimensions. The culture aspect rests in providing modern leadership and change management. I provide only a passing reference here to this dimension. My presentation here is focussed on the structural and process dimension.
I describe 3 “laws” of scaling. These are observations or empirical laws. Then I set out 10 patterns that I have found helpful over nearly a decade of doing this with many organisations as a consultant and coach.
You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
SolutionsIQ: Automating Application Development, SAFe, and Other Takeaways from AgilePalooza Seattle
“How do we get the servers to be as responsive as our software development?”
SolutionsIQ developer/coach Ben Tomasini asked this question last week at AgilePalooza in Seattle. It was just one of the many topics that he and a number of other speakers covered at the event. Attendees learned about system automation, scaling frameworks such as SAFe™ and some of the interesting ways that agile and scrum are being used at development organizations around the Seattle community.
Check out Ben’s ESPN highlights reel from the event:
For more information about SolutionsIQ visit the AgileIQ Blog.
It’s been a while [again] since posting anything new at www.implementingscrum.com.
I see people are sharing the information (all around the world) in cubicles and Scrum team rooms. People are linking comic strips from their blogs, using them in presentations, and including them in books.
The Chicken and Pig cartoons here are now firmly established as folklore in the Scrum and Agile communities today.
People either love it or hate the story; however, an amazing thing is happening — people still talk about them AND they are still used to help start tough conversations in software development.
And yet I ask myself, why am I not posting *regularly* here anymore?
The answer is pretty simple. I’ve moved on and evolved my interests over the years. The comic strips are obviously not my area of *passion* anymore; they don’t get me out of bed excited to take on the world daily anymore.
That. Is. OK.
There is still a boat load of information out here to share, consume, and learn with one another.
Heading into 2015 (and beyond), I’ll still be maintaining this site and will continue to push out regular reminder postings with the old comic strips (and possibly some new information as a topic is relevant). If you want to help me on this, please let me know (the ball is in your court on this one, and YES I am serious with this invitation).
Where else am I headed into 2015?
A concept I am calling, “One Shiny Object.”
I’ve been on working with people (all around the world) for many years and have found that my passion today is helping people figure out their own concept of a, “One Shiny Object.”
It’s about keeping things simple. Removing complexity.
Very similar to the concepts we live in the Scrum and Agile world. It’s beyond that now (and probably has always been… I’ll be using the tools in that box heading out of just the software development world).
Out on twitter (@mvizdos there) you can catch me doing this (almost daily) now. At conferences, this is something I am passionately talking to audiences about.
With clients, it’s all about this:
Interested in following me (Mike Vizdos) on this new journey?
Please jump over to www.OneShinyObject.com and let me know your name and e-mail address; from there, we’ll branch off from the topic of this blog about Implementing Scrum and then you’ll see what we can do together to focus on your One Shiny Object.
Amazing things are already happening. Join me (still FREE!).
You’ll still be getting information here about Implementing Scrum, and I reiterate my humble request that you to get involved here to keep things relevant in your world of Scrum today.
It’s all a journey!
I’ve delivered quite a few training classes over the last several years, most of them in how to effectively utilize Scrum and Agile tooling in the delivery of software. And yes, I’ve relied heavily on Powerpoint decks to get my message across, doing my best not to read from the screen, but deliver the information in an engaging way. If you’re a trainer, you know this can be a tough thing to do. You gotta be on, and know your subject matter inside and out. Without that, not much else matters. Once you’ve got that down, it’s a matter of conveying the message and helping the learners understand. How we do this varies. Much of it is our own personal style, and what we learned from someone else along the way. But here’s a dirty little secret… many of us trainers aren’t really professional trainers at all. We just know something so well that someone made the decision to throw us in front of people to share our knowledge.
I’ve seen some really good showmen/women as I’ve attended training classes over my career in IT. It’s a truly impressive (and sometimes entertaining) thing to watch; a performance really. They know their stuff, no referring to their notes, lots of eye contact, voice inflection and fluctuation, a few jokes thrown in for good measure, smooth flow and spot on timing. And we all clap at the end. Bravo! I aspired to be that polished.
But a colleague recently told me about this idea called ‘Training from the BACK of the Room’ based on a book of the same name by Sharon L. Bowman.
In true Agile fashion, I tried it out in my Agile tool training classes. At first, it seemed uncomfortable to me. I had my old slide deck down pat and knew it well, so who better to share all that great information than yours truly? In my traditional training model, I was the ‘sage on the stage’.
But I vowed to really give this new thing a shot. I still used a Powerpoint deck, but the number of slides went from about 100 to 15. Training became more of a conversation, a series of exploratory exercises, and discussions afterward.
Rather than providing step by step instructions on how to perform a certain exercise, I’d give them a challenge, like…
- Identify at least three help options in the tool.
- Create two user stories. Name one ‘Add book to wish list’, and the other ‘Remove book from wish list’.
- Create an Epic called Manage Customer Account
- Create three child backlog items under that Epic called…
You get the idea here. I’d have similar challenges around Release Planning, Sprint Planning, blocking stories, closing stories, setting up notifications, creating and sharing conversations, reports, etc.
I get folks heavily involved in showing the class what they did and how they did it. Dig into their thought process. Recognize and appreciate that others may have done the same thing differently, but achieved the same result. Literally have them come up to the front of the class and drive on my laptop, showing us all how they did it (see pic above). I thought I’d have to call on folks to get participation, but I didn’t really. They mostly volunteer. They’re eager to share what they learn. I encourage folks to work in pairs (paired learning), but not everyone does, which is ok.
The feedback was surprising (to me anyway). Initially, I felt like I wasn’t really doing my job as a professional trainer. But folks loved this new format! The feedback forms (which were better than my previous classes) only told part of the story. In addition, people would come up after class and tell me they had never had a training course like this before. The majority of students really liked being engaged in this new way. To be fair, there was a minority that didn’t really care for it. I understand.
Oh, and yes, I literally did train from the back of the room (sometimes the side or front too). Most of my time was spent walking around, helping folks who got stuck or had questions about the exercises/challenges I gave them. The struggle is part of the learning.
At the end of the day, what I learned is that being the ‘sage on the stage’ is not as good as being the ‘guide on the side’. I know… it rhymes, but it’s true. We shouldn’t expect a performance from our trainers, or to sit in awe, as they impress us with all their knowledge and showmanship. That’s not the point. As students in a training class, our goal should be to learn something that hopefully helps us do your jobs better. As a trainer, it should be to help them learn. When they go back to their real job, they should be able to recall what they learned, and apply it to their own unique situation. As Trainers, we can make it stick by engaging students, challenging them, asking questions and guiding.
If you’ve attended training like this, what did you like (or dislike) most?
If you’re a trainer, have you seen this method applied to training other than ‘technical ‘or ‘tool’ training?
Over the last few years, I’ve worked with numerous teams. One thing they all struggle with is backlog grooming. They all know they need to do it. Unfortunately, they all seem to struggle with when to do it or who should do it. The most interesting struggle with backlog grooming happened two years ago. The “story time” meetings took place at the beginning of a month-long sprint. The manager stated, the work to be completed and delivered during that sprint had to be refined within the same sprint. This helped explain why the team thought they needed month-long sprints. When I asked why they would try to refine work the first two weeks of the sprint and then complete that work the second two weeks, you know what their answer was? “It said to do it like that in the Scrum Guide!” After I clarified their misunderstanding, we established a cadence to continuously mature the backlog. A few select people would participate in the scheduled meetings. We would reserve capacity from each sprint to get that work ready for future sprints. The team was able to shorten their sprints to 2 weeks. They more than doubled their delivery rate without increasing defect rates. With that as an example, over the last few years, I have evolved my practice of backlog grooming. Let’s look at some key dates in the evolution of backlog grooming.Evolution of Backlog Grooming
2005: “grooming the product backlog” is mentioned by Mike Cohn on what is now the Scrum Users Yahoo Group;
I always have teams allot some amount of time to “grooming the product backlog” to make sure it’s ready for the next sprint.
2008: A formal description of “backlog grooming” is given by Kane Mar, under the name Story Time, and recommending it as a regular meeting
I call these meetings “Story Time” meetings….Although they are not a formal part of Scrum, I’ve found that Story Time greatly improves project planning and reduces confrontational planning meetings, which are all too common for many teams. A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work.
2011: The practice of “backlog grooming” is called “backlog refinement” and promoted to an “official” element of Scrum with its inclusion in the Scrum Guide
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
2014: Derek Huether from LeadingAgile evolved the practice of backlog grooming with one of his clients, to allow the practice to work better at scale, calling it a “Progression” workshop.
When operating at scale, my client deals with different problems than a standard Scrum team. They’re dealing with separate lines of business. They’re dealing with multiple delivery teams for each line of business, to include external vendors. They’re dealing with a portfolio roadmap that has annual plan items and budgets. Our strategy encapsulated the entire product delivery value stream, while ensuring we had enough architectural runway. We progressed work to be consumed by delivery teams, via a series of workshops.Progression Workshops
Our progression workshops differ slightly from the story time meeting detailed by Kane Mar and the refinement meeting mentioned in the Scrum Guide. Counter to Story Time, we don’t invite the entire team. Instead, we have elevated the workshop to a group some have come to know as a Product Owner (PO) team. The group of people within the PO team will vary, depending on the line of business. Yes, there will be a Product Owner (Product Lead) and facilitator, but from there we’ll include the development lead, testing lead, and an architect. We’ve found two key challenges when operating at scale. First, is there a well defined backlog that is ready enough to be consumed by different delivery teams? Second, is the work being queued up to the delivery teams free and clear of other teams. That is, have we decomposed it in such a way that we’ve minimized dependencies on other teams? Beyond that, in order to achieve some degree of architectural runway, we continually refactor existing platforms. Architectural changes are not only made incrementally but we require an architect to be present at every progression workshop.
Counter to the Scrum Guide, I’m not going to be proscriptive as to how much capacity the PO Teams do/should commit to progression workshops. The goal is to have enough work ready for delivery teams to consume for a few sprints.
When progressing work, we do expect some artifacts to be generated, to contribute to the teams understanding of what will be developed, tested, and delivered. Below is a partial list of potential artifacts. To be clear, we do not expect all of these to be generated.Potential Deliverables
- System Context Diagram
- Dependency and Risk Work Items
- System Architecture Guidance Acknowledgement
- Use Case Diagram and document
- Business Process Flow
- Known Business Rules
- High Level Technology Alignment
- Architecture Backlog for Planned Work
- As-Is Data Contracts
- Feature Work Items Assigned to Delivery Team
- Feature Business Value and Acceptance Criteria
- Feature Stack Rank
- Test Strategy
So, that’s the high-level view of the Progression Workshop. Most of the time, a feature will require two or more progression workshops before work is ready to be consumed by a delivery team. Once features progress to a defined level of shared understanding, the delivery teams assist in the decomposition of features to user stories. In this way, work is decomposed to the right level of detail for each delivery team.
I’m curious, how have you scaled feature development and backlog grooming in your organizations? What mechanics outside of the standard Scrum process have you found useful to refine work to be completed by delivery teams? Have you evolved Story Time or backlog refinement?
If you’ve gotten a glimpse into Axosoft culture, you know we like to tack on “Axo” to as many words as possible (I.E. AxoCulture). Anyways, call it Axoween or whatever you like – we hope you had an amazing Halloween, ’cause we sure did!
Participation was high this year at our annual costume contest. Even Axosoft was not safe though from the Frozen pandemonium sweeping the nation… yes… Elsa, Olaf, Anna and Kristoff made an appearance!
The AxoGirls of the office kicked it up by going the superhero route – of course adding their own flare with handmade tutus! You know, there’s nothing fancier than a Thor in a tutu.
However, AxoGents were not to be outdone. Some went the route of video game characters (Luigi and Payday), some were tv and movie characters (Top Gun Maverick and The Office Three Hole Punched Jim). Some even joined the ladies in the superhero theme; we had a Deadpool, Tony Stark (Axosoft founder Hamid), and a rather dashing Captain America (see adorable puppy in photo).
But the winner of them all was Hodor and Bran from Game of Thrones… or as we like to call him, John!
Since Rally announced our support for SAFe™ 3.0 in July, we've been hard at work making sure our support for the latest Scaled Agile Framework® is all-encompassing.
We know that scaling agility takes more than a product. In Dean’s words, “a fool with a tool is still a fool.” To benefit from agility at scale, we need to learn a new way to do portfolio and program management. Training and education are key, especially at these levels. Expertise from those who’ve helped others adopt SAFe can be a huge time-saver. The focus that SAFe 3.0 brings to the portfolio level only emphasizes the need to have good scaled Agile practices in place.
As a whole solution provider, Rally’s consulting, platform, and expertise are key to making you successful at scale.Rally Program Launch with SAFe
Rally Program Launch with SAFe provides the right coaching, training, and tooling to establish Agile release trains quickly and effectively, so you can coordinate teams of teams to deliver value to the market in as little as three months. With one of the largest and most experienced stables of Agile coaches and SAFe SPCs (recognized by Dean himself), Rally can get you started in time for your next planning event and help you ensure a successful outcome.Rally SAFe Training
Rally has made major updates to our Agile Portfolio Management class, the only class in the industry that teaches you the critical mindset shift necessary for modern portfolio management. The class covers SAFe 3.0 portfolio concepts, as well skills like investing in themes rather than projects and steering work rather than resources. We’re offering two Agile Portfolio Management classes before the end of the year (London, Nov 13-14 and Boulder, Dec 9-10): join us and be ready for Q1. Don’t forget our Leading SAFe class, which provides training for the Lean-Agile Leader role -- now recognized on the “Big Picture” as a key role in driving Agile and lean concepts adoption.SAFe Support in the Rally Platform
We’ve also enhanced Rally Unlimited Edition with features that directly support SAFe 3.0:
- The Release Planning Board supports the development planning cadence (“Develop on Cadence”) and allows users to create realistic release plans that consider feature size, cost of delay, and development capacity. Each “release” tracks a Program Increment (PI.)
- Portfolio Kanban provides value stream tracking with all the great user experience you expect, such as state-specific policies and customized card content.
- Lean portfolio metrics with the Rally Insights™ Time in Process (cycle time,) Productivity, and Predictability charts give you important feedback on your performance.
- ART metrics, such as the Release Burnup with projection line (get it in our Rally GitHub Community,) let you see iteration and release progress (SAFe Release Train level metrics.)
- Milestones support the development delivery cadence (“Deliver on Demand”) decoupled from the development planning cadence. Milestones, shown on the Portfolio Timeline below, provide the ART participants with a “Release Feature Progress Report” to help steer work towards business goals.
SAFe at RallyON Europe
To our European friends attending RallyON! Europe next week in London, don’t miss the opportunity to boost your scaled Agile expertise by attending one of our post-conference classes, 13-14 November. For a complete list of upcoming classes, visit our Agile University calendar.
We hope to see you on the SAFe train in 2015!Catherine Connor
As usual… I’ve gotten a little sidetracked on my Agile 101, 102… series of posts. I’ve got the 201 post half finished, but haven’t been able to spend the time getting over the hump. That said, I want to divert just a little and talk about agile in general, explore some of what it is, and a little about where it’s going. I think we have created a bunch of confusion in the marketplace. I am under no illusions that this post will be the definitive explanation, but I spend a TON of time talking to people and level setting before I can have any kind of intelligent conversation on agile, so I want to explore some of the points that I think resonate.
Can We Define Agile?
First of all… back in my early, early days of community involvement at V1… I was really wresting with this untangling language around agile. I used to break the conversation into a few key areas: project management, product management, leadership thinking, and technical practices. Today, I find myself taking a slightly different angle. I tend to see agile discussed as a cultural phenomenon, sometimes as a set of practices, and sometimes as a way of structuring and governing how your company works. More often than not, agile is setup as a counterpoint to some of the most ridiculous examples of bad management we can come up with in an industry.
From my point of view, agile is all of these things collectively and none of these things individually. Agile is about having a rational system of work in place where people are engaged and can thrive, but one that produces the business outcomes that our stakeholders are counting on. When we get too myopically focused on one aspect over others, it is easy to start talking in platitudes and one-size-fits-all adoption approaches. Every organization I’ve ever worked with has been vastly different and, while certain patterns apply, solutions are always unique to the people that are impacted by the change.
The first line of the Agile Manifesto says that we are uncovering better ways of developing software by doing it and helping others do it. How we implement agile is supposed to change over time, and how it changes should be guided by the values and principles in the Manifesto. The challenge is that the values and principles are supposed to guide the practices and structures we choose to implement. The values and principles don’t live by themselves or in a vacuum. To successfully implement agile, we have to have a system of delivery and supporting practices which enable the values and principles to be lived out.
The Problem With Big Companies
I’ve been focused on what I call the ‘Big Company Problem’ since I left CheckFree more than 7 years ago. Back in the day, we were building complex systems of systems for the financial services industry. Products of products. Multiple overlapping and intersecting value chains. Heavy traditional governance and pockets of agile scattered throughout the organization. This was an environment with specialized business domain expertise, multiple diverse technology stacks, an organization that demanded 5 9’s reliability where downtime immediately impacted revenue and incurred penalties. How does one begin the process of agile adoption in any meaningful way in an environment like this?
Many of us suggest that ‘big and complicated’ is the problem and that we need to be ‘small and simple’. I agree… but, these companies ARE big and complicated so the question becomes HOW to help them become small and simple. Just saying BIG is bad and you should be SMALL doesn’t help. How do we get there? What is the path from A to B? Is adopting an agile value system enough? In the presence of the right value system, will the right delivery systems and practices emerge? In the presence of the right practices, can I impact the end-to-end system of delivery and make the cultural changes I need to make?
The problem with the culture first mindset is that there is practically no way to change enough hearts and minds to get everyone on board fast enough to produce results in the timeframes we are working against. Even if I could get everyone to adopt an agile mindset, we have real governance issues and audit requirements that often cannot be changed overnight. We have tightly coupled technology stacks, tightly coupled product requirements, imbalances in capacity and demand, and bottlenecks all over the place. Solving the problem is a matter of redesigning the system of delivery. Not everyone is an expert in designing systems, and even those that are don’t agree on the best path forward.
There are clearly some places where a culture first transformation can work. There are definitely some where it won’t. As an industry, we have to have an answer for when the scale and complexity are such that self-organization around the problem isn’t a viable approach. Again, the right company, the right business problem, the right underlying technology, and the right group of really smart people can get a ton of stuff done given the right degrees of freedom. There are some environments, though, where this is recipe for chaos. I personally think it is irresponsible to suggest that cultural transformation is going to fix this. We cannot always assume that if enough people ‘get it’ agile will begin to take hold.
Here is another one that I believe is driven by our long history of thinking of agile as a set of processes. Most top down organizations are accustomed to using process to pull together disparate working groups and coordinating activities across them to create larger deliverables or achieve broader organizational objectives. In many of these cases, the underlying organization, and maybe even the underlying organizational culture, doesn’t matter all that much. All we need to do is document a process that people can follow and, provided they actually follow it, we’ll get the outcomes that we desire. People assume that agile as a process will behave similarly.
Agile is different. You can’t take a set of functionally siloed teams, operating under heavy management control, traditional phase gate governance, fixed time, cost, and scope constraints, and tell them to do whatever process they want. You can’t tell them that agile is okay, but then hold them accountable to live in the same organization, under the same rules, and under the same constraints as a waterfall organization. The agile process in and of itself doesn’t make any rational sense outside the context of a team based organizational model, an agile governance framework, and a mindset that allows for some adaptation to the unknown. It doesn’t work.
Practices alone will never solve this problem. All we end up with is a bastardized form of agile where people go through the motions, but where agile doesn’t live up to the value that was promised. In order to do agile well, you have to have teams, you have to have backlog, and you have to have the ability to produce a working tested increment of product at the end of each iteration. This involves rethinking how you go about forming teams, how teams work together, and how value is coordinated. In the presence of teams and practices, I believe that the right thinking can emerge.
I’m a big believer that agile culture and agile practices are essential for long term sustainable organizational agility. That said, I don’t think you can train your way into it and I don’t think you can believe your way into it. I think you have to start with a team based organizational design where the flow of value is governed across teams using an adaptive governance model, based on lean/kanban principles, where WIP is limited, capacity and demand are balanced, bottlenecks are identified and dealt with, and management is invested in improving the overall system of delivery. Only within this kind of organization can an agile culture emerge and agile practices thrive.
I also don’t think that people intuitively understand these kinds of systems and I don’t think that most organizations will self-organize their way into them. Most people tend to think about optimizing what they can control and getting better only at what they are responsible for delivering. People are often self-interested and will consciously or sub-consciously advocate for system designs that are in their best interests. In the long run… forming teams, decoupling dependencies, reducing complexity, and creating an ecosystem where small, independent teams can self organize within their boundaries is the only model I believe will work.
So, I agree that we need to be small and simple, but getting to small and simple… much of the time… is a process of forming teams around business problems and technology, progressively decoupling them from each other, reducing dependencies, and dealing with bottlenecks. There are real issues facing large enterprises, there is a ton of momentum around the old way of doing things, real organizational and technological constraints, and just telling people to self-organize around a new system of delivery… one that they may or may not collectively understand… is often a recipe for disaster.
Structure then Practices then Culture
We do though have a bit of a chicken and the egg problem here. How do I get permission to start an agile transformation if I don’t have a leader with the right mindset to give it a try? I’d suggest that you at least have to have a leader that recognizes there is a problem and is open to alternative ways of solving it. I’d suggest you begin by focusing on your business goals, articulating a strategy to create a team based organizational model, and model based on iterative and incremental delivery principles, one that uses agile and lean methodologies for delivery and governance, but that operates within the operational and cultural constraints of the existing organization and it’s policies.
You teach this organization agile technical practices and management practices at the team level and adaptive lean governance practices at the program and portfolio level. You teach the organization how to deliver with reliability and predictability within that framework as you build trust in the new way of working. As we learn the capability of the new model and build trust with the organization, we create the opportunity to influence hearts and minds and create the environment where people feel safe to take chances and absorb risk with new ways of thinking that challenge their old ways of thinking.
The Role of Leadership
These kinds of changes have to be led with top down intent, but with a bottom up implementation. People have to be engaged and do ultimately have to be bought in. That said, buy-in will only come when people realize that the new system is working and the new system rewards the new behaviors. Once we have the rational team based system of delivery, new practices that support operating the new model, and a new mindset that enables us to unleash the power of the new system of work… we can start really improving as an organization and start tapping into the promise we’ve been reading about with agile all these years.
IMO… it’s not so important to talk about agile as structure, practices, or culture… it really is all three. It doesn’t matter if we are talking about agile as a set of management practices, an approach to product development, a leadership framework, or an approach to software craftsmanship. It is all of those things as well. But when it’s all those things living in an integrated system of delivery, where all the parts work together, when they are no longer in competition, where we really start to see the value. Things have to work as an integrated whole. It’s the working together as an integrated whole that is going to make this take off. Not just some team level agile practices or pockets of agile mindset in a vacuum.
Maybe this is all obvious, but there is a lot of debate about where to start with your agile transformation and what’s important to focus on first. If not debate, then different messages and approach in the marketplace around what works. I think that many folks work in broken organizations and can’t see a path forward… because without the support and direction of your senior leaders, nothing I’m talking about is even possible. As an industry though, once we get the messaging right, you are going to see more and more agile adoptions led from the C-suite, not in silly Dilbertesque caricatures, with informed intent around how to build organizations with a systems based perspective.
In most large organizations, bottom up is not an option without leadership acting from the top.
The post Some Thoughts on Agile Transformation in Big Companies appeared first on LeadingAgile.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]