Agility is an Organizational Value
âą
10 gefĂ€llt mirâą4,166 views
A presentation I gave walking through the basics of Agile Lean and Scrum to an organization that was looking to deploy the use of Scrum and the Agile philosophy for business management. Scrum is a powerful framework that can be applied outside of a software development context to bring Agility to any organization.
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ăhnlich wie Agility is an Organizational Value
Ăhnlich wie Agility is an Organizational Value (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
Agility is an Organizational Value
- 1. Agility is an Organizational Value
- 2. What is your â Product â
- 3. Traditional Execution Models Touchdown Right?
- 6. Chaotic environments require self organization around basic patterns with continuous re-assessment
- 7. Your processes need to match the relative stability of your environment
- 8. OK â so where do we start?
- 10. People & Interactions Over process and tools
- 11. Results Over comprehensive documentation
- 12. Customer Collaboration Over contract negotiations
- 13. Respond to Change Over following the plan
- 14. Lean Thinking
- 15. Eliminate Waste
- 16. Amplify Learning
- 17. Decide As late as possible
- 18. Deliver As fast as possible
- 19. Empower The team
- 21. See the whole
- 22. Scrum: A self organizing adaptive system
- 23. Scrum Master Scrum Team Product Owner
- 24. Backlog A sorted list of priorities
- 25. Sprint A time boxed work cycle
- 26. Daily Scrum Each day, same time, 15 min max
- 27. Impediments Anything that slows the team down
- 28. Management Systems Are critical to adoption
- 30. Organizational Rhythms Daily Weekly Monthly Quarterly Annual Intra-day (Drive Gear of the Company)
- 31. Strategy Process People Technology Pilot Solidify Rollout Alignment Organizational adoption of Agile is an iterative learning process
- 32. Case Studies
- 33. Balihoo has rolled out Agile with the Scrum framework across all business functions
- 35. â Scrum in church? Of course! How else did God create the world in seven days?â
Hinweis der Redaktion
- What does the word Agility mean to you? Sports athlete?, cheetah, Blue Tang Fish? To me: ability to be reactive WITH speed, strength, and grace Agile is reaching buzzword status There are articles about how many companies are âgoing Agile in 2010â, how Agile is in the budget and they are going to âpurchaseâ Agile this year. This scares me. It scares me because these companies will try and fail, and then say things like âit just wasnât a fit for our organizationâ. The thing that these executives need to understand is that agility is about people. Agility is cultural, and to be truly successful at such an initiative, Agility needs to be an organization value. Today's Goal The goal of today's presentation is to present a framework called Scrum that allows an organization be more operationally agile Where does the word Scrum come from? Itâs a formation in Rugby. Two Foundational Elements that support this framework 1. Agile: came out of the world of software and is more of a philosophy on how teams need to think about agility inside of an organization 2. Lean and more specifically Lean thinking that lays out some operational principals start to guide organizational operations towards hyper efficiency. Once we get a brief overview of these two elements we will move into the basics of the scrum framework, which is the car that will operationally get you where you want to go. We will then close with some case studies on some organizations that are doing this. Its not important that you retain all of the foundational details â more to be aware of them so that as you start to study and apply the Scrum framework you will begin to make connections.
- I am going to be using the term product in these discussions, but this should be treated as a generic term. A product could be physical, or electronic, a good or a service or a combination. It can be the net sum of why your team or organization exists. Even in our company â since we started as a software shop when we say product â people limit their perspective to the actual software, but our business has become much more complex than that. Because of the stigma, we often now use the term âwhole productâ which is the complete set of offerings including software and services. Then take that to your teams. For example what is the âproductâ that marketing produces? The key thing throughout this discussion is to be thinking about your what your âproductsâ are. What value are you producing.
- Think about your business or any business as a game where the objective is to move the ball down the field to a place where you can score. For example â lets look at your business as a football game. Football is an interesting game in that it does have feedback loops â you execute a play â see if it worked, try something different ect. As long as you make some incremental gain down the field in 4 tries you are still doing ok. Does it always result in a touchdown?
- Unfortunately the model of set your strategy and go execute does not always result in a touchdownâŠ. Many organizations execute plays like a football team. The call is made and the team agrees to go off and execute the play. What if the other team is just bigger, or they read your playâŠ. Luckily in football you have 4 tries to get the ball forward⊠So as long as you are playing against other football teams this strategy can be successful, however what if you are competing against another team that also has the same objective of move the ball down the field, but they donât follow the traditional rules of the game? http://marketing.balihoo.com/blog/marketing-planning-systems/0/0/startups-moving-the-ball-forward
- In football the rules of the game do not change very often, however think about the world of business. Heraclitus stated 500 years before the birth of Christ that the only constant is change, so change has always been with us. What is different now is the rate of change. People by their very nature of averse to change. Change is uncomfortable, and because organizations are run by people they are also inherently averse to change. Those that can grow comfortable with change will be more successful.
- If change in business is constant - It is my position that business is much more like a game of rugby than a game of football. In Rugby there is also a goal of moving the ball down the field, but there are far less rules â to a casual viewer it might almost seem like there are no rules and can appear chaotic with the continuous nature of play. Chaotic environments require self organization around a set of basic patterns⊠and this is the key â with continual re-assessment. Without retrospection things will degrade, mistakes will be made over and over again, and the team will not be able to sustain itself. Much like Rugby â the team operates under a basic set of patterns with self organization on the field by the team. Even the origins of the sport itself are one of change. In fact the legend of how rugby started was from 1823 when during a game of soccer one of the players picked up the ball and started running with it. However you can see today that there are many people playing the game of business in a very traditional way getting bypassed by someone who ignores the rules and picks up the ball.
- Not all environments are the same, and their relative stability changes over time For example 15 years ago the music industry was a stable environment that had worked the same way for a long time. It was like playing in your backyard. As most of us (except for maybe the executives in the recording industry) now know â the music industry is now like a birthday party in your back yard with a jumpy house m- a very unstable environment⊠but what is more fun to play in? Unstable doesnât mean bad or risk, except for those averse to change. Unstable means opportunity. Unstable is when a football team is forced to play against a rugby team. So even if your bus environment is relatively stable now will it be destabilized by someone else or is there an opportunity for you to do it?
- OK to summarize what we have just talked about: Change is constant Change creates chaotic environments that need self organization to survive and your processes need to support the relative stability of you environment So how do we do that? Lets look at the first of the two foundations I mentioned at the start â Agile.
- Lets first take a look at Agile. Agile [Software Dev] concepts started back in the mid-late 90âs but the in Feb of 2001 at snowbird resort in Utah, 17 experts in the software development field got together and created the Agile Manifesto. It started with 4 values. With some small changes to remove the âsoftwareâ spin, these values can be applied to any business
- First let me say that I am a process guy. I have done a lot of process re-engineering and I have seen a lot of complicated processes, which are sometimes necessary. Process work very well when things can be defined. The month or year end close process for a companies books is a great example. However The less definition around the objective, the more that strict process can hinder progress. Tools are means to support, but often they become the central point of focus. Have you ever been on a project that used Microsoft project or similar? This is especially prevalent in software where cutting edge tools can move from a means to an end to being the end game. People and the interactions between them is where creativity and problem solving happens.
- People get confused with this one a lot. It does not mean that you do not document things or that documentation is bad. Its means that the focus should be on the results â whatever you are producing. In software this means you value working code that supports a customer need - that is what is valuable to the customer, not reams of documents about requirements, design, testing etc. In our case, we are releasing new and change features to our product every 2 weeks. Requirements are a few bullet points and maybe a quick screen moc, testing is done on the fly with development or happens automatically, and product docs are release notes. With Education how would this apply? Results might be students with salable skills â not the class projects or the notes from all the classes attended? Think about when you build a new house. The plans are useful, inspections are worthwhile but at the end of the day, you would rather move into a house where everything works as expected. With education â I would go as far as to say â the results is a job offer, or whatever you expect to happen post degree rather than the degree or all the documentation along the way.
- Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the solution. Yes, they likely wonât get it right the first. Yes, theyâll likely change their minds. Working together with your customers is hard, but thatâs the reality of any job. Having a contract with your customers is important, having an understanding of everyoneâs rights and responsibilities may form the foundation of that contract, but a contract isnât a substitute for communication. Successful companies work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way.
- People change their priorities for a variety of reasons. As work progresses on your product your project stakeholderâs understanding of the problem domain and of what you are building changes. The business environment changes. Technology changes over time, although not always for the better. As we have discussed change is a reality most businessâs, a reality that your process must reflect. There is nothing wrong with having a project plan, in fact I would be worried about any project that didnât have one. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant. One thing to note: A lot of people are now saying that strategic planning is not useful anymore. My feeling is that Agility without strategy is chaos. The problem with strategic planning is that most organizations donât have a structure in place to support frequent revisits to adjust strategy.
- Now that we have talked philosophically about what it means to be agile, lets look at the second part of the foundation â Lean thinking. This starts to form the operational guides to being agile. Lean is a process engineering technique originally started by Toyota to improve their manufacturing process. It is a practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination
- 7+1 types of waste Muda Overproduction Unnecessary Transportation/handoffs Inventory/WIP Motion Defects Over Processing/Excess Quality Waiting **Intellectual The Seven Wastes of Software Development Overproduction = Extra Features Inventory = Requirements Extra Processing Steps = Extra Steps Motion = Finding Information Defects = Defects Not Caught by Tests Waiting = Waiting, Including Customers Transportation = Handoffs
- How do you amplify learning? Use of shorter work cycles to support test and learn very quickly Shortening the feedback loop with customers Direct dialog with the customer â no filters Examples for us: We release working code interactively every 2 weeks We use varies customer engagement strategies to gather feedback on things we have release and even those that we have not released If your main customer is internal this âshouldâ be easier (but is often overlooked)
- Just in time⊠decision making In uncertain environments better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions An iterative approach with short cycles promotes this principle â the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the product Quote from Jason Fried â 37 Signals E.g. â Our recent IFA prototype
- The sooner the end product is delivered without considerable defect, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. Without speed, decisions cannot be delayed. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product. Examples: IFA protoype â development This course
- There was a traditional belief in most businesses about the decision-making in the organization â the managers tell the workers how to do their own job. Has started to dissipate we have moved into an information society, however it still exists in various flavors This does not mean to abandon leadership, but let the people who add value use their full potential. Leadership vs Management: set direction, align, enable, motivate vs plan, budget, organize, staff, track, control A pillar of lean is âdevelop peopleâ Agile says â find motivated people and trust them people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for â purpose within the reachable reality, with the assurance that the team might choose its own commitments The key however to making this work is having a framework that allows the team to be successful.
- Build Integrity In External (perceived) Integrity: totality of the product achieves a balance of function, usability, reliability, and economy that delights customers Internal (conceptual) Integrity: the product components work together as a smooth cohesive whole Key to this is to have excellent information flows from customer to the people building the product as well as upstream and downstream processes related to the product. Eg â in software: Automated testing In business: the right level of process can support this â Lean tools such as value stream mapping, 5 whys problem analysis etc
- Products are not just the sum of their parts Donât ignore detail but beware of temptation to optimize parts at the expense of the whole Optimizing parts leads to sub-optimizing the overall product Make sure you are measuring success at the right level to ensure âseeing the wholeâ Eg â A new microsite launched to support the marketing efforts of a new product. The site could be optimized and look great but if the team doesnât understand then target audience and they donât target correct â it can sub-optimize the entire product. We face this with providing the rich service offerings that compliment our software offering. In summary: Think big, act small, fail fast; learn rapidly
- Scrum: Not: a methodology, a defined process, a set of procedures Is: a framework with a simple set of rules â a self organizing adaptive system
- 3 roles Product owner: owns the product backlog/priorities Scrum Master: primarily responsible for removing impediments of the team Team: Pulls works from the backlog, executes Product owner should not be the same person as the scrum master.
- Items in the backlog are called user stories or more often just âstoriesâ Stories are value producing activities (to the customer) Stories are broken down into tasks A backlog can only have one order at any given time (bubble sort) Stories are estimated with points
- Sprints have goals Ideally at the end of a sprint â the work produced is âproduction readyâ Sprints: Pull system â Team commits to completing the work, org commits to not changing priorities within that window. Managed with a âsprint boardâ â a kanban â pull system for moving stories from start to finish
- A communication tool Strict format: 15 minutes. Everyone stands 3 questions: what did I do yesterday, what am I doing today, what is standing in my way from achieving my goals Pigs vs chickens Not for reporting up â communication between team members.
- Can be very tactical â blocking a specific story progress Larger â similar to a backlog â a list of issues that are slowing the team down as a whole (eg â a team member working on two teams etc) Should be prioritized just like the product backlog
- First: You can have a hyper efficient team but without supporting management systems they will not be hyper productive. They might product a lot of things fast but not necessarily the right things Second, Agile is a journey â it needs to be supported and lived by management just as much as by the operational teams.
- OODA Loop - Observe, orient, decide, act PDCA (Demming Cycle) Everyone understands feedback loops, but there are two main issues: Companies forget the most important part â closing the loop -they may close the loop but the cycle time is so long any learning's are lost
- What we are talking about today are the bottom 2 or three circles, however feedback loops can and should shift up in larger and larger increments. Scrum can actually be applied at all of these levels.
- Adoption Path As mentioned Agile is an organizational journey. There are no set timelines. However there are stagegates at which point you can consider moving to the next level. Many start at Pilot, but never see it thorugh. Most organization that are successful never go beyond the first two columns.
- Monthly sprints (except software development)
- 2 phased approach No software development â used to manage their portfolio companies
- Scrum as an Agent of Change: (Moving away from identifying and fixing problems to actively seeking impediments. Itâs moving from blaming and shaming to naming and claiming responsibility) Working as a Team Transparency Clarity and Focus Flexibility in vocabulary Iterations and continuous improvement