I have thought that the interaction within a framework like Scrum and what it brings to the world of software development has some definite inroads into mitigating the risk of our endeavors. In short, to simply deliver. For a company adopting Scrum for the first time, here are some of the reasons why:
What we do is to break up big things in agile. Even time itself. Instead of here you go, see you in 6 months, which is a really LARGE time-box… We prefer the ability for a program to connect, realign, adjust, share discovery MANY times in much smaller durations so that we can respond with changes that are not left to aggregate, grow larger, and simply fall upon us at the end. We are slowly changing an organization’s ability to be able to respond quickly. This can be a cadence, or tempo, but the chance to do this and coordinate across individuals within a team, teams, programs, and even within an organization at an executive level is a force multiplier. The time box helps us perform other breaks, loose couplings, explorations and growth/stage based building. It forces us to think critically, innovate, and simplify self-driven achievement. By pausing to learn from it, early and often, we will realize much larger wins. such as Here are some more time-box benefits:
- Narrowed focus to prevent distractions within a foreseeable goal (Limit task Thrashing or the shiny object distractions)
- Make mistakes but not fail (discover and uncover things early and limit the time to do so)
- Sprint length (every 2-3 weeks – and yes there is the 1 week Shock Therapy by Sutherland)
- a small part of the entire commitment, delivered and used by the customer early.
- See effect of change on team (a new team member) – velocity drop/increase or the work
- Adjust priorities. There is nothing like urgency to help us determine what is important. It is unfair to list a 100 things as the same priority. It also forces us to recognize the limitations and reliability of our own capacity to do the work. (If I only had 48 hours my bucket list would be very clear, concise, and achievable)
- Not STUCK, frozen in analysis paralysis but move on into somewhere actionable.
Under this I include communication, context and perspective switching, learning, and much much more. We are seeking to identify EVERYTHING it takes to get through this organization and into the customer’s hands. It uncovers the organization itself. We characterize the capacity of our teams to perform the work, and we improve upon it.
- Bring kingdoms into the light - Less isolation more engaged in continuous thinking
- Break down CYA and your fault – we all own this, how can I help? My recommendation is…
- Break down hidden processes – want to tie integrate, add value, bring technology, learning, perspective, change, experience
- Everyone making as informed a decision as they can
- Sharing best practices
- Shakes loose the comfortable decay many processes can fall into
- How it aligns directly with what needs to be done
- Question and help represent what needs to be done and when
- Through functions, roles
- Through the Business and the organization around the teams
- Through teams themselves
- Are we working on the right thing in the right way?
- Did we get into our riskiest areas first to learn more?
- Earn Trust by doing what we say
- Getting better at predicting what we can do
- Convergent expectations
- Vetted solutions
- Celebrate wins
- Listen to the feedback and actively seek it out
Coaches hold practice for anyone in sports… Practice, practice, practice. We want to get is right, we want it to feel natural. It doesn’t seem right in business to say practice, and instead we focus on our competition. When it is easy to move within the framework, we also allow ourselves a space to reflect, contemplate, try, innovate, as well as simply get in there and play. These events are done over and over, and the expectation every time is not just a check box on a list. Did we improve it? What would have been phenomenal? We lessen the risk whenever we know ourselves, our team, our organization and how to coordinate in attacking the work. Scrum iterates on these things:
- Team-Delivery (Review)
- Shippable Software
- Retrospective (Program and Team)
- predictability of aggregates
- empirical analysis – we indirectly see and understand
- right sizing and right timing the work
- our own estimates -
- the people doing the work estimate it
- We become better at breaking work up, and estimating it
- scope or valued work
- Adjustments to make the work Sustainable effort
- Improving processes and practices
- Improving Team skills
- Discovery (leveraging our experience and trials)
Ultimately the organization has not chosen Scrum but, redirected themselves with an emphasis on supporting teams that create software. Teams at many different levels. At times this is a cultural shift. A choice in how we recognize, reward, and motivate these teams and enable their achievement. Empowering a team is one form of reward. These teams are comprised of the different roles, functions, and surrounded by others which will help solve, assess risk. A team exists as well to mitigate the risk of the availability, talent or skills of a single individual. Ultimately, the team is also there to help mitigate, solve, or assume that risk. Our skills, experience, work and perspective together will collaboratively make this solution the right one, the one the customer expects and we can be proud of.