Martin Hinshelwood

dsfasdfadsfdfasfda

You need quality enablement to achieve predictable delivery for your organisation which takes effort to achieve. I do a lot of ALM Assessments for companies and almost every customer that I speak to has unpredictable quality in the software delivery that they receive from their teams. This is not always the Development Teams fault and is often the result of an organisation that is finely tuned to minimise the ability to have a defined and predictable level of quality. In most cases this is due to a lack of a bar that quantifies the minimum things that need to be completed in order for and organisation to understand what i involved in each delivery. If you have no bar for delivery and thus no idea what needs to be completed for each thing to be delivered then how can you expect to make accurate (or at least as good as we can get) prediction on when things are going to be delivered? You would effectively have no empirical evidence to rely on for predictability of delivery. In addition, the varied quality level results in more bugs in production, which then puts those individuals’ responsible for adding features under more pressure. If you put developers under pressure they will consistently and increasingly cut quality to meet the same deliverable. Figure: The Iron Triangle In addition many product backlogs lack acceptance criteria leaving the Development Team to guess at the basis by which the customer will accept that something is complete. Indeed because if this lack of acceptance criteria backlog items can often be deceptively large which puts the development team under greater pleasure for delivery and thus the cut quality. Fix quality for improved predictability The only way to successfully create predictable software delivery is to fix 3 of the 4 points of the Iron Triangle. In traditional software development quality is the hidden value and if you fix everything else it is Quality that suffers. Quality should be anchored with an explicit definition. Definition of Done – Your DoD is the fixed measure or explicit definition of quality for your software development process. It is a short measurable checklist which mirrors shippable that can and is applied to every unit of work delivered. It can be hard to define but without it we don’t know how much work needs to be done in order to ship any backlog item. Apply it at least to the output of the iteration and ideally to every backlog item that you complete. Acceptance Criteria – While the DoD is applied equally to every backlog item acceptance criteria only applies to an individual item. All conversations between the Development Team, Product Owner and the Business should be reflected in the acceptance criteria so that things that are discussed are mot missed. This also serves to understand scale and encourages breaking down backlog items into smaller units of work. Once you understand what needs to be done to complete an item, overly large items become transparently obvious. Automated Builds – Having automated builds that can measure the quality of your software is paramount to minimising the amount of work that the team needs to do to verify the software and creating automated acceptance tests and unit tests increase the validity of those builds. Ideally you should have an automated test (UI or Unit) for every acceptance criteria that was added to the backlog item. Automated Deployment – Having automated deployment will force the team to create working software and allow you to build and maintain something that will minimize the cost of delivery. If the Development Team knows that the business can choose to ship at any time they are then under pressure to maintain that ship-ability and thus quality. Doing all of these things will serve to make quality the goal not the lack of it. Conclusion The way that we have traditionally measured our development teams have finely tuned them to fluctuate quality in order to meet aggressive delivery schedules. However this fluctuating quality only serves to reduce our ability to deliver and annoy our customers when they find the resulting bugs. The goal is to increase quality not reduce it but first we need to be able to measure that quality and enforce it. Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)

Many companies have started searching for self-organisation. That ideal or nirvana where teams can figure out how to work together effectively with limited or little direction to solve problems. Many, including some of my colleagues, believe that this search for self-organisation is ultimately fruitless. While many of our customers don’t initially believe in its existence because they have never seen it my colleagues think it impossible because they see company after company fail to achieve it. This is mostly as companies that call use are not ding so because they are awesome but instead because they see that they have some problem that needs looking into. These companies, while realising the need to change, tend to have an organisational structure and culture that presents an anti-pattern for self organising teams to ever exist. Oh, you will occasionally find small pockets of self-organisation within an organisation but if anyone tries to roll this dynamic out, it is ultimately demonstrated as unworkable due to those anti-patterns and those required traits and patterns are then ground out of people. Realism dictates that we need to move slowly towards self-organisation in a way that will build up the self esteem of teams and create an environment for them to thrive. But the organisation also needs to have courage and conviction in order to realise it as the path to agility is a bumpy one and long, depending on how traditional they are to begin with. Why self-organisation at all? If we don’t have self-organisation then don’t we have our least skilled and appropriate individuals (project managers) determining how, when and were any work should be completed. Should we not have the knowledgeable and skilled professionals that we hired to do the job of developing the product decide on the how, when and where? If we don’t have self-organisation then how can we hope to hold the Development Team accountable for delivering the work? They can always blame the organiser! If we don't have self-organisation then how do we know how much time should we spend on training of new individuals? Do we guess at their current skills or evaluate them with standardised tests that have done so well for our school system? Or should we not rely on their peers to make sure that each team member has the skills and knowledge required to help the Development Team deliver… Without self-organisation how do we effectively encourage individuals to work as a team and be responsible for the results? Encouraging self-organisation There are many thing that can impact your ability to get to self-organising teams. Here are a few items to ponder: Team Accountability – Moving from Individual accountability for tasks, to collective accountability can improve both the team dynamics and the management of those teams. Peer-pressure within teams and a clear but slight pleasure to deliver can reduce any concerns around collective under performance. Team Identity – Although related to accountability, organisations wants to aspire to achieve high-performing teams which is impossible without a team identity. This identity is the same ideal that sports teams strive for and results in a camaraderie that is part of any high-achieving team. Team should be expected to move through Tuckman's stages of group development (Forming | Storming | Norming | Performing). Small Teams – Creating dedicated teams of 6+-3 people will allow you to manage the complexity of the work and the people more effectively. A team should work from a single ordered backlog so that they get good at working together, understanding the backlog, and delivering. You may need multiple teams to work through the backlog at a rate that is acceptable to the customer but you should see significantly better results with many small teams than fewer large teams. Consistent Teams – If you are forever inter-changing team member then you will be forever re-forming and never even enter storming let alone getting to performing. If you cant get to performing then high-performing is totally out of reach. Stop thinking in individual allocation to projects and start thinking about team allocation to projects. This will also help reduce your management overhead and improve your communication by removing layers between the customer and the team. Remember that the biggest killer of self-organising teams is a manager who just needs to make sure… Conclusion Without self-organisation, no matter how much we try, all we can ever have is a glorified collection on individuals that think and operate as individuals. Just like with sports teams we want to have those individuals identify as a team, to work together as a team and function as a team. The only way to achieve this is to have them be a team. You would not want the coach to swap out players on football game for every match? How effective would that be? So don’t do it to your teams… If you get really good at self-organising teams you may find your organisations formula to high-performing teams… Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)

Does your company culture resemble Survivor? Do you have a culture in your organisation where individuals that help others are considered slackers for not getting their own assignments complete? If you are trying to achieve agility it is imperative that your team members work together to solve problems. I am not saying that you have to do pair programming but you have to have a culture where collaboration and working together is the norm. This is one of the two main roadblocks to agility ( the other one being requirements management) that companies hit time and time again early in their agile adoptions. Changing this part of your culture is something that has much wider implications than just improving your teams ability to deliver value. It is a harbinger of changes to come and if you can change this one thing, you will be more able, and committed, to making more changes to your culture going forward. The goal is to have a culture of change where each of your teams are running small low risk experiments in processes, practices and tools every iteration. It is the catalyst to wider company adoption and buy-in and it requires a certain amount of courage and discipline to achieve. Release planning and predictable delivery As with most impediments to the path to agility this is an issue of culture. To change culture you need commitment and courage not just from those at the coal face but from executive leadership on down. If you are trying to adopt agility from the bottom up you will have limited success and ultimately you are doomed to failure. The problem is in how individuals see their work and treat the work done by others. Over many years the US, and in some industries the UK, have moved towards the Survivor model. This is where each individual is measured and encouraged to look out only for themselves. They work in an isolated bubble where they are force fed activities and they are solely responsible for activities in their queue and those individuals are often stack ranked each year. This process only services to isolate not just individual but also their skills and their knowledge. Ask yourself this: If you won the lottery and never returned to the office what would be the impact? You need to foster unit mentality If you have see the Mel Gibson movie “We were soldiers” there is a really memorable phrase that has value in the software space. “Learn the job of the man above you, and the man below you”. Software development is a collaborative effort of a Unit (Development Team) working together to achieve a goal. We need to understand each others knowledge, skills and even quirks in order to be effective. It is critical to instill a sense of Team and not Individual within your organisation. If you are going to get anywhere on the path to agility you need to let go of the matrix. You need to realise that allowing team members to work on more than one project at a time only creates the illusion that there is more work underway. The reality is simple…individuals that switch between projects lose at least 20% of their time per project that you add. The loss of the 100% worker There is even a greater loss of not working in dedicated Teams; you lose most of your peoples individual ability to solve problems. Software development is all about problem solving, its about puzzles and developers excel at solving them. Remember that software development it is always product development. However if you give your Development Team members the wrong puzzles you will not be utilising them for the thing that you actually employed them for…solving the puzzles. Its the background processing power of a developers subconscious that you can utilise to solve the most complicated of problems. Developers will figure things out in the bath, or while playing with the kids or driving home from work. Unfortunately if you give a developer many projects to work on and they have to switch often ( you know… to show progress on many things at once) then what is the greatest problem in their world? You should have guessed it by now: its the problem of juggling their workload. So the problem that their subconscious is trying to solve is how to juggle that work more effectively. This has the effect of stretching the amount of time that each thing takes as it takes many more cycles for the developer to figure out the problems and thus your software takes many more months to deliver than it should. Conclusion Don’t have a company culture that resembles Survivor and instead opt for one of Teams. These Teams will be a force multiplier to your ability to deliver software and this will give you a competitive advantage. Don’t wait until your competition figure this out! Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)

Did you know that the DOD has made it illegal to do waterfall? For the first time in many years the Department of Defence (DOD) in the United States had made a major update to its procurement rules. They can no longer be held accountable for holding up our industry, and being culpable for its inability to move towards agility. The last vestiges of the old ways are gone. You may be thinking “But who gives a crap what the DOD does?”. Unfortunately in the USA almost everything in IT revolves around how the DOD develop software and work with vendors. If you are a vendor that works even third hand with the DOD you used to be bound by law to create software and work in a stage gated and distinctly waterfall manner. Oh, many teams tried to do agile anyway. However they could only do this within each stage and this is the situation and source of Scrumfall, Agilefall, WaterScrumFall and all of the other pretending to be agile processes out there. The DOD has influenced Universities by requiring that they create engineers that work within their model and by providing and creating jobs that function this way. How can one learn to be agile in a world governed by waterfall. Indeed our own Ministry of Defence (MOD) has had the same influence, maybe from their own rules but also as a result of working with the Americans and within their rules (like how airports in Europe require you to take your shoes off even though you are not flying to the USA. (2) be designed to include— (A) early and continual involvement of the user; (B) multiple, rapidly executed increments or releases of capability; (C) early, successive prototyping to support an evolutionary approach; and (D) a modular, open-systems approach. 804: Implementation of new acquisition process for information technology systems With the new rules there is now freedom to deliver more frequently and iteratively through the western world and this effect can be seen in recent UK projects as well as in the US. There is no better government site than http://gov.uk! It is quickly becoming the envy of other governments in its simplicity and ones ability to quickly and easily find the information you need. One of the defining projects of the last 10 years that has resulted in this change in the USA was the resounding and public failure of the Sentinel project buy the FBI. I created this presentation based on work that I have done with Scrum.org and I use it at organisations that have a little more inflexibility and stubbornness than most. Usually at these customers I hear phrases like “You cant do that here.” and “We are not a software company.” Thus looking at the FBI is a good one as it is not software and government. If the government can do agile then by golly everyone can. I always like to start a presentation by looking at some data. For good reasons have we moved to agility from waterfall and above you can see that as of 2011 we are three times as likely to succeed doing agile as we were under a waterfall. Succeed – Project was on time and on budget Challenged – Project was delivered but not on time or on budget Failed – Project was not delivered Although we still have a lot of challenged projects we can vastly reduce the failure of them. In addition one would hope that an agile project that fails, fails only a few short iterations into the project so the costs are a lot less. Waterfall projects tend to fail near the end as it is not clear what will be delivered, or not delivered, until at least testing commences. Can you imagine a green screen terminal application delivered in 1995? Just to put it in perspective, Windows 95 was available. Hell, my Atari has a graphical UI. Well the FBI launched their obsolete criminal records system in1995 and used technology that was museum quality at launch. This is all to common with projects that take many years to complete and even more so on government projects. So what happened next? At first all was well and the FBI Director commissioned a 3 year project with a budget of $390 million but very quickly things start to drift and he had to go, cap in hand, to congress and ask for more money. As this is typical government fair he obviously got it but in 2005 there was still nothing delivered. Not a single piece of working functionality existed after 4 years and an extra $170 mullion. How would your boss react if you had nothing to show for 4 weeks… let alone 4 years? Would you still have a job? In this case obviously the best idea would be to throw away the last 4 years work and start again with a new vendor. Yes… that’s it…now we can really deliver. Obviously having already spent over $400 million on vaporware the new vendor just needs more time and more money. It obviously also makes sense to pick not only a large defence contractor, co they have a good record of delivering high quality on time and budget, but also not a software company. The rational for this I do not know but that is just what the FBI did. However after 4 years not even a third of the work was complete and almost 90% of the budget had been spent. Indeed rough estimates to complete the project was another 6 years (10 years total) and another $351million (grand total of $772 million.) So with over 400 people working on the project the total waste so far is over $700 million and the project is 9 years in. Remember that the out-of-date green screen terminal application has now been in place for 15 years and Windows 7 is just around the corner. We already have the iPhone and iPad so what the hell are these muppets playing at! Its time for a different tack… The new tack was an agile one and for these guys it was more of a jibe. They created a Scrum Studio in the basement of the hover building and found the 40 best folks that they could to run with the new format. This being the second reset with so many years and dollars under it there needed to be results and quick. Not only did they deliver incrementally but they were code complete with only one year of work and $30 million spent. That’s right… I am not missing a zero. Unfortunately the project had taken so long that the hardware that had been bought by the previous attempts was vastly out-dated and needed to be replaced as obsolete. In early 2012 the FBI shipped to production on the new refreshed hardware and saw significant improvements for a much lower cost. Conclusion The benefits of working in an iterative agile process is now painfully obvious to both the FBI as a result of Sentinel and partly as a result to the US DOD. Higher success rate – you are three times more likely to be successful with agile Cost Effective – As you always have working software you can stop at any time without waste Low Risk – You only ever have one short iteration of risk at a time. In the UK we have a government wide lean-agile initiatives that are producing awesome results already and in the USA lean-agile has effectively become the law. Deliver Early and Often - This principle is aimed at changing the culture from one that is focused typically on a single delivery to a new model that comprises multiple deliveries to establish an environment that supports deployed capabilities every 12 to 18 months. Incremental and Iterative Development and Testing - This principle embraces the concept that incremental and iterative development and testing, including the use of prototyping, yield better outcomes than trying to deploy large complex IT network systems in one "Big Bang." Rationalized Requirements - User involvement is critical to the ultimate success of any IT implementation, and user needs must be met. However, this principle also recognizes the need for users and requirements developers to embrace an enterprise focus across a portfolio of capabilities with established standards and open modular platforms vice customized solutions to ensure interoperability and seamless integration. Flexible/Tailored Processes - The Department's IT needs range from modernizing nuclear command and control systems to updating word processing systems on office computers. This principle acknowledges unique types of IT acquisition and embraces flexible and tailored-and risk-appropriate-IT paths based on the characteristics of the proposed IT acquisition. A new approach for delivering Information Technology capabilities in the Department of Defence So with the radical change in approach from two western governments these positive messages should filter down through anyone who does business with them. The tides are changing… Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)

Gathering the metrics for Evidence-based Management in software organisations can be a strenuous task and I have a number of customers that are fretting on what to collect and from where. Here I try to create an understanding of the 'what' that we need to collect. Evidence-based Management for Software Organisations is a framework from Scrum.org to help organisations focus their efforts on most valuable improvements and monitor their effect for the organisation. In my experience, organisations recognize agility as a means to improve their value, yet tend to lack focus and commitment to moving towards it. This is mostly because of entrenched traditional ideas and a resistance to change that comes, in the west, from a "if it ain’t broke, don't fix it" mentality. Let's forget for a moment that it has been proven over and over again that small experiments that fail quickly are what produce results. Let's forget as well the 20 years of the success of agility, when there is focus and courage. We need evidence… That evidence is there. You can find study after study that shows that agile practices work, that moving to agile values works better. So why don’t people listen? Still, I hear: "That will not work here", especially in the enterprise. In the successful enterprise its worse: "We are fantastic and we know best as we have been doing it this way for many years with success". Unfortunately the measure of success has traditionally been: delivered on time delivered on budget with the features that were required upfront Unfortunately this measure of success does not take into account how much 'value' is delivered to the customer or users. If you take another look, as the Standish Group in Boston has, at the above traditional measures of success (used both by PMI and Prince2) you find that this measure equates to very little value to the customers. Forrester is currently trying to encourage organisation to start measuring the value that they are delivering rather than how they are delivering it. How we measure value up until now in software delivery has been to either rely on the Product Owner, or to start introducing traditional measures from formal process… and we already know where that leads. The dark side! So what can we measure? Sure Scrum has traditionally focused on the team, and the best measure for a team is "Remaining Work". From that we can create Velocity and Burndown to help the Product Owner plan and the Development Team deliver. Simple… but organisations are not simple and need a way to really measure success in an agile fashion. If we can provide organisations with some standard agile metrics maybe, just maybe, we can pull them out of the dark and into the light. This is why, with all the kafuffle over "scaling Scrum", Scrum.org has been biding its time and doing its research. Most of the scaling Scrum methodologies out there miss the boat on measurements. Not only that they have [come under much fire recently] for providing way too much rigor in the wrong places for a "one size fits all" solution. If you can't have "one size fits all" at the team level you sure can't do it at the organisational one… I have a written and spoken about Evidence-based Management already: Evidence-based Management for Software Organisations (n): A process for measuring, diagnosing and improving the value an organization derives from its software investments. It improves an organization's ability to compete on its software capabilities by using evidence to focus investments on areas that will create the highest value for the entire organization. Its iterative, incremental approach to guided change helps organizations control the risk of disruption. You can find out more about Evidence-based Management for Software Organisations on http://ebmgt.org and I want to talk a little more about the gathering of metrics for monitoring. Let's face it, it's not just Organisations that want to understand their return on investment for their hard earned cash spent on improving their process and practices. There are good consultants out there that want to understand the value that they are bringing to their customers so they can inspect and adapt as well. I, for one, want to focus on delighting my customers. To bringing them the most value for what they pay me. I have traditionally done this by simply looking at how happy my customers are. While this is an important metric is only one piece of information in a web of interconnected data that I can use as evidence of that improvement. That is why I went to Boston last month to complete the training and assessment to become an Evidence-based Management Consultant with Scrum.org. I need to understand how my advice affects an organisation that I am working with. How else can I know if my advice is good? Guesswork? That sounds a little…archaic. There is a better way… There are really three groups of metrics that make sense at the organisational level. There are metrics that monitor the current value being delivered, the time to market and your organisations ability to innovate. We need to gather these metrics at a point in time as soon as possible to provide a baseline for where the organisation currently is. We can then reassess the organisation at intervals, probably no more than quarterly, which will allow us to look at the trends over time. Current Value Metrics The current value metrics look at data that gives an indication of the company’s success in the market place. These metrics should be gathered once across the organisation with the organisation defined as consistently as possible across instances. They might include: Revenue per Employee – Gather the revenue generated by the product you are evaluating and employees contributing to its success Cost of Product Domains – Gather the IT expenses associated with the product Employee Satisfaction – what percentage of employees are engaged? Customer satisfaction – what percentage of your customers is marketing your products or services on your behalf? All of these are easy to collect and most are likely readily available. Many enterprises already do some form of employee and customer satisfaction which we may be able to use. However the timespan of the collection of the metrics should ideally match. Time-to-Market Metrics These metrics look at how quickly an organisation is able to bring new innovations to its customers. They might include: Release frequency – How often do we put new features in the hands of our customers? Release stabilisation – How much time are we spending on getting something “done” to “really done”? Cycle time – How long does it take for us to move new features from idea into customer’s hands? Ability to Innovate Metrics These metrics look at an organisation’s ability to continue bringing innovations to its customers in the future. They might include: Installed Version Index - What percentage of your customers are able to take advantage of new features on the latest release of your product? Usage Index – What percentage of our features does not provide value to our customers? Innovation Rate – What percentage of our budget is spent on innovation? Defects – How much technical debt are we accumulating? As you have already likely surmised with these metrics it makes sense to gather them per application. We can then average the results to figure what they are across the entire spectrum. While these figures may vary wildly between applications as long as you use the same formula you should get comparable results. Scrum.org suggests aggregating these into one, easy to track metric – the Agility Index. This number becomes synonymous with the value an organization is getting from its software development capabilities. Conclusion For the first time we can now, as consultants, monitor the improvements we are making in organisations. Even better, organisations can use these metrics to demonstrate the value that their investments in agility with training and consulting are bringing them. This is a fabulous step forward in our understanding of software delivery. An easy, simple way of measuring our progress towards process improvement. Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)

A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based Management Consultant. I was talking to my father about it when I got back and was surprised that he recognised many of the practices and tools. In the 1990's my father (John Hinshelwood) was a regional director of a large estate agency (realtor) in the UK. For many years he worked from a single shop in Glasgow running his own business. In 1988 he sold his business to a large Insurance company that was trying to get its ailing Estate Agency business to turn a profit. It was failing at this task, however it was not long before my father's talent for detail was noticed and within a few short months was appointed a directorship. Using evidence-based practices he turned a lossmaking business into a profiting business for over 5 years. Three months after he left they were making a loss again! They had not changed to embrace Evidence-based Management as an organisation and without my father's stewardship they slumped back into the old ways. A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to become an Evidence-based Management Consultant with Scrum.org. Evidence-based Management is a new approach to looking at the value you are delivering with your organisation that is based on evidence rather than the traditional 'gut feelings' of managers. It allows you to really look at what you need to improve to make the most of your investments in agility. Organisations spend a lot of time trying to understand the value that they are getting in their pursuit to agility and often spend time pouring money into areas that are seeing minimal improvements. There may be other areas where they could get much more value for money but they either don't know or don’t understand where and what they are. These large organisations struggle to move towards agility no matter how much they might want it. Some of this is a people issue but often it is the reality of scale that gets in the way. There is lots of help for these organisation but how can they be sure not only that they are on the right path but that the help that they are getting is providing the value that is advertised. For this we need to do something and then look at the result to determine the value. This is what Evidence based Management is all about. Evidence-based Management (EBM or EBMgt)'s roots are in Evidence-based Medicine and evidence based policy. The idea is to bring scientific methods to the front of the way we do things and EBM's goal is to bring it front and centre in management of organisations. Evidence-based management entails managerial decisions and organizational practices informed by the best available scientific evidence.http://en.wikipedia.org/wiki/Evidence-based_management In order to even begin to understand where we need to go we need to understand where we are right now. If management can effectively understand where we currently are then you can much more easily prevent backsliding to the old ways once you improve. This is in essence why scientific and proven practices should replace the more traditional 'gut feeling' used prolifically in management. Evidence-based Management and how it applies to general organisational improvements as well as software development organisations is described well in “The Leaders Guide to Radical Management by Steven Denning”. We, as the software industry, have been focusing in the wrong place. The revelation from The Standish Groups research that success, as measured by traditional PBI metrics, does not equate to value to the customer, is damming. Couple that with Forester's salient advice to focus on measuring the value delivered to the customer, it is obvious that things need to change. Steven Denning looked at many successful organisations across the world, even companies that were once successful, to see if there were any commonalities between them. He found that when companies focus on the products or services that they deliver they are rarely successful. In instances when they are successful, that success tends to be very short lived, no more than 5-10 years. You only have to look at the rise and decline of many companies in the FUTSI 500 to see the impact of focusing on products and services only. So what is the secret? The secret is to focus on your customers. Focus on what you can do to delight them. And then identify metrics of leading or lagging indicators of customer delight. If you focus on measuring and optimising these measure of customer delight then you will create the most relevant products and services to make your company a success. And if you continue to focus on your customer, you will sustain that success for many more years that your competitors that don’t. While the leading metrics and evidence of high quality value delivery for an Estate Agency differ from a Software Company, there are similarity's. In fact I was once asked by a customer what the industry standard metrics were in the software industry. I had no answer at the time, and in fact failed to come up with my own that would provide the desired leading measures. But even with the proliferation of measurement systems popping up everywhere, there are few that follow the evidence-based approaches described in “The Leaders Guide to Radical Management by Steven Denning”. One such emerging dataset is the Agility Index from Scrum.org. Scrum.org have identified three key areas that we need to focus on. Figure: Agility Index from Scrum.org for leading evidence for the impact of change We need focus on value (Business Outcomes) to make sure that we are producing something that our customers value while not alienating our employees or spending too much money doing it. We need to focus on lead time (Time to Market) to make sure that we can take those things of value that we are producing and quickly get them, in short order, into the hands of our customers. We focus on quality (Ability to Innovate) to make sure that what we do deliver works, is easy to use, has useful features, and does not have a high maintenance cycle. These three groups of metrics and merged into a single agility index using a weighted calculation to gives us a consistent idea of where we are now. We can then look at the trends of these figures over time and make sure that we are heading in the desired direction. This figure gives your organisation a value for return-on-investment in your process improvement efforts. Figure: Agility Index from Scrum.org shows Measure, Diagnose, Improve in action The goal now that we have our direct evidence is to diagnose, as a doctor would, what changes are most likely to bring the most value to our organisation. To do that we need some extra circumstantial evidence that we can use to diagnose which improvements will provide your organisation with the most value. There are two tools in our arsenal to help us gather that circumstantial evidence: Practice Backlog - a indicator we can use if the maturity of the practices, tools, architectures, and standards that your organisation is using. To help measure this Scrum.org has created a practices backlog of things that we know, through long experience with software organisations, helps them become more effective at delivering value. This practices backlog contains more than 300 practices that are ordered as there are many dysfunctions that can arise from skipping over certain practices. This gives us an understanding of your organisation's practice maturity. Assess People - another good piece of circumstantial evidence is the skills, knowledge, and understanding of the people that are involved in the delivery of the value. This can be assessed individually and Scrum.org has created assessments that it already uses to evaluate knowledge after training. Scrum.org has over 3 years of experience in measuring individuals knowledge of agility and what it takes to be agile. We can leverage that knowledge and use their existing assessments for Developers, Scrum Masters, and Product Owners to gain visibility of their maturity of knowledge. Find out more on how Agility Index can help you business Using the circumstantial evidence or organisational maturity from the practice backlog and the assessments we can better diagnose where to focus investment. With the leading direct evidence we can understand the impact of our changes. These together from the backbone of Scrum.org's implementation of Evidence-based Management for Software Organisations. Evidence-based Management for Software Organisations: A framework within which people can address complex organizational change, while productively and creatively improving the enterprise and its products. You can find out more about Evidence-based Management for Software Organisations on http://ebmgt.org Your organisation probably has metrics that you use now. However ask yourself if these metrics can tell you how much value that their projects delivered last year. If not the should focus on value… and agility path includes a bunch of tools that are optimised to help you to understand and optimise that value. Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)

There is a better way than staggered iterations for delivery that will keep you on the path to agility. I have seen many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. They believe that by creating a timbox for planning, development and testing that we can get closer to agility and move away from our traditional models. Unfortunately the actual result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. In many cases it can be a significant step backward that will take many painful years to rectify. Figure: Example of staggered iterations for delivery I have heard this called many things. Water-Scrum-fall or maybe Scrummerfall but whatever you call it the reality is that this is just small waterfalls and in the case above not really that small at all. The problem with staggered iterations for delivery In the diagram above we have an 18 week cycle from inception to delivery. That’s more than 4 months between ideation and delivery with a lag of 2 months to even get feedback with a 2 month lag for all subsequent feedback. Worse this is the most expensive kind of feedback as the Coding and Testing teams have already moved on from the thing that is getting feedback and the result of that feedback will be more expensive to implement. Indeed worse yet if QA finds something that needs fixed we have maximised not only the cost to fix but the mean time to repair as the developers have moved on. And what do they do with that feedback? How is it prioritised? Do they quit what they are doing immediately and fix the previous iteration or do they wait until after they deliver this one? What if they are blocking QA? Does QA sit around till the end of the iteration after the one they reported the problem in? The solutions to staggered iterations for delivery We need to foster teams over individuals and make those teams responsible for the delivery of working software. To get that we need cross-functional teams that can turn ideas into that working software. And we need to do it often. Cross-functional teams – We need to have everyone on the Development Team that is required to turn the Backlog Item into working software. If you were a property developer you would have access to joiners, plumbers, plasterers and electricians. You would create a team of individuals that was sufficient to complete the daily work on site with experts on hand as needed. This is the same process for a Development Team. You should have all of the skills that you require on each team to turn the forecast backlog items into working software each and every iteration. Have experts on hand for those tricky items but minimise the dependency that you have on them. Asynchronous development - Ideally you want all of the disciplines that you need to complete each backlog item to work together to deliver the software. This is more than handing off between disciplines but moving towards everyone always working at any point in time. This is a hard one to achieve but is the responsibility of the team to figure out how. Test first – Test first is about not doing any work unless there is a measurable test that elicits that work. Creating tests from acceptance criteria will make sure that your team is working on and understands the next most relevant thing to be worked on and that you have built what the customer wants. Additionally, creating unit tests before code will make sure that your coders are working on the most relevant problem, and that each line of code that they complete does exactly what they intended. The long term benefit of this is that we now have an executable specification that will result in an error if a future change breaks existing functionality. You are doing it wrong if you are not using test first Working software each iteration – If you don’t create working software at the end of each iteration you have no way of knowing what really needs to be done to create a working increment. If you do four iterations of two weeks before you think about creating a working increment, how much work (re-work really) is left that you need to complete to really be done? To really have shippable quality? If you don’t have working software at the end of each iteration you are making sure that your business can’t ship out of band, no matter how much it wants to. Quality Assurance requires no testing – If you consider that all testing is done as part of the sprint, then the only thing that needs to be done as part of the QA gate is to review the test results and coverage and determine sufficiency of those results and coverage. If you are taking more than four hours to QA two weeks of Development then I would suggest that the Development Teams work is not sufficient. These things will al individually help and if you are doing all of them together your value delivery and quality should start to increase over time. Conclusion The expected result of staggered iterations would be an increase in rework and in technical debt. If you are moving from a 4 year iterative process to a 4 month one you will see value, but your process will be opaque and will only reduce your ability to deliver working software. Yes your cycle time will be reduced, but you can do so much better. Published at Scrum.org with permission of Martin Hinshelwood, Professional Scrum Trainer at naked ALM Consulting. (source)