5000-1 Foxes in the Henhouse

Steve KitchingIn the past week, we have seen one of the most remarkable sporting achievements by an unlikely underdog here in the UK. Leicester City FC, of the English Premier League, won the league with two games to spare, beating illustrious teams such as Manchester United and Chelsea to the top.

This was a team with no stars; in fact, it barely escaped relegation a year before, which bookmakers made 5000-1 outsiders to win the title.

How did they do it? Some say it was the discovery and subsequent reburial of Richard III in Leicester Cathedral after his remains were found in a local carpark, bringing the team this run of good fortune.

The truth is that the victory was due to an incredible display of teamwork and commitment. There were no egos, just a drive to perform and support each other to consistently deliver results time after time.

Other teams failed, including my local side, Newcastle, where egos and attitudes ruled and so performances and results degraded.

Why am I talking about this on a software blog? We can all relate this situation to our experience of teamwork in the IT world. I’ve worked on teams where egos dominated. Whoever shouted the loudest would win, and inevitably the team would struggle to meet its goals. Compare this to teams who worked together harmoniously and delivered the goods time after time. The way a team works together directly affects the results.

This lesson can apply to any team in the IT space, but the mantra of teamwork should shine most predominantly in the Agile space, where the team(s) should pull together for a common goal.

How do you improve team culture and habits? We suggest the AgilityHealth Radar, which is a strategic retrospective that focuses on the top areas that affect team performance and health. With the results, there is a clear path forward to improved team culture and thus improved results.

So, are you a Leicester or something else entirely?


Steve Kitching
Estimation Specialist

Written by Steve Kitching at 05:00

How Do I Calculate Estimates for Budget Deliverables on Agile Projects this Year?

Scope of this Report

This report discusses the tension between organizational need of budgetary data for planned Agile deliverables vs traditional project cost accounting. Agile project lean-budgeting best practices at the portfolio level are highlighted to illuminate the importance of estimating and budgeting as Agile scales in an organization. The Scaled Agile Framework (SAFe) portfolio and value steam levels, as presented in SAFe 4.0, provide the backdrop for this discussion.

Budgetary Needs of the Organization at Scale

Small to medium sized businesses with 100 or less developers organized to develop, enhance or maintain a small group of software products can account for the labor and material needed with straightforward software cost accounting methods. This is true whether they are using traditional waterfall methods or Agile methods such as Scrum because, typically, such businesses are small enough to ignore or work around the differences between the project perspective of waterfall and the product or perspective of Agile.

Larger organizations with hundreds to thousands of developers, organized to develop and maintain a portfolio of software products, are more challenged in software cost accounting and budgetary planning or estimating early in the planning cycle for a given year. Estimating and budgeting early presents challenges to Agile credibility as well as governance.

Software leaders in the trenches deal with day to day change while higher-up executive or management seek predictability and certainty. This contributes to preliminary rough order of magnitude estimates becoming memorialized as commitments instead of a work-in-process numbers to drive conversations and decision-making. This is driven by the financial reporting needs in the executive suite rather than the workflow optimizing needs of the development activity.

Financial Reporting Tensions Rise as Agile Scales

Public accounting standards guide CPAs and CFOs shaping financial information to quantify business-created value. That value can be in the form of a hard good, such as a car, or a soft good, such as software or music. You can consult the Financial Account Standards Board (FASB) repository of standards1 and statements on software cost accounting for the specifics but in general, you can either expense or capitalize your costs when developing software. Choosing when to do so is left up to the organization (and their reporting needs) as long as they can defend the decision per the standards and they are below a certain size. Consequently, initial budgetary estimates are important inputs into the process because they allow for the reporting professionals to partition or plan the expense vs capitalize decision based on schedule

In the traditional waterfall world of software development, it is conceptually easier to decide when to expense and when to capitalize as the diagram below illustrates.

Figure 1: Waterfall Project Stages

Waterfall Project Stages

A waterfall software project has a distinct beginning and end with clear ‘phases’ identifying activity versus value created. Code, integration and test produce actual ‘capital’ value. Requirements, design and maintenance are ‘expenses’ required to produce ‘capital’ value. Also, substantial waterfall projects are longer in term and length and involve more resources, both labor and material. Longer term this makes it seem “easier” to estimate and schedule reporting events.

Agile projects, with most using the Scrum method, are inherently different in structure and execution employing an incremental value creation model as illustrated in Figures 2 and 3 below. This is a cyclical model where short bursts of activity create immediately available value (shippable product increment). Multiple cycles, iterations or sprints are crafted together over time to create releases of software product. Estimates can be made as to how much time will be spent designing, coding, testing, etc, in Agile and the work of people like Even Leybourne
suggests that it is not difficult to deal with the CAPEX/OPEX distinction but auditors like to see timesheet records to support estimates of the amount of time spent, say, designing versus coding. Splitting time recording like this for Agile teams within a sprint is hard to the point of being impossible. DCG Clients use approaches similar to those described by Leybourne to deal with this issue with little friction but only after they have convinced their auditors.

Figure 2: Agile (Scrum) Sprint Cycle

Agile Sprint Cycle

Figure 3: Multiple Sprints to Produce a Release

Multiple Sprints to Produce a Release

Estimating within an Agile cycle is a real-time small-bore activity focused on small pieces of potential value that is more often called “planning” in the Agile context. These are not estimates that cover the beginning, middle and end of an Agile initiative (or project if you prefer that term). These real-time estimates, done with relative methods and unanchored to any financial or engineering reality are unsuitable for aggregation and turning into a budget. You cannot aggregate bottom-up estimates to a budget in Agile.

However top-down needs persist for Agile budgets and early estimates to support not only prioritization but also the expense vs capitalize allocation process. As Agile scales, so do the reporting demands. Furthermore these early estimates or budget must be as reliable and consistent as possible, be based on a repeatable, verifiable process to increase confidence and accurately represent the value creation activity. If you cannot bottom-up aggregate Agile estimates, what about top-down?

Epics, Story Points and Releases

Epics are the large, high-level stories that can usually be broken down into many smaller stories. Epics drive Agile development, from the top, to create business value in the form of shippable product. Epics form the contents of portfolio and product backlogs rather than sprint backlogs and as such they are the level of stories most familiar to executive and technical leadership. Despite being high-level, they are brief, concise and unelaborated just like normal stories and, hence, almost impervious to early estimation due to the relative lack of information.
The Agile method, at the team level, is designed to decompose Epics into smaller units such as user stories. These user stories are estimated using relative methods such as story point, t-shirt sizing and other techniques. The Agile team continuously elaborate these user stories, in each sprint or iteration, leveraging end-user involvement and team dynamics to create incremental value. Discovery of requirements is an intimate process conducted by the team and not the organization.

At some endpoint in the Agile development a Release is designated ready and complete for shipment to the marketplace. This all costs money so how does the organization decide to fund one or more Agile teams when initial Epics are hard to estimate?

Portfolio Level Value Creation and Reporting

The term portfolio is common in financial and investment conversation while programs is a term common in planning and organization. For example, Federal contractors, building large military systems, use the term programs to cover the planned series of events, projects and other activities, such as in the F-22 Raptor Stealth Fighter Program. When the methodologists at Scaled Agile, Inc. (SAI) constructed their Scaled Agile Framework (SAFe) approach, they recognized that “Program” is a valid term to organize multiple subordinate activities (within multiple Agile teams) and applied it to their lexicon2. While there are several different established approaches to scaling Agile, the SAI methodologists seem to have paid the most attention to high-level budget challenges so we will spend some time on their approach in the report.

Using “Portfolios” to group multiple Programs seemed a common sense next step because of the financial implications rising from larger scale activity in an Enterprise. Agile is driven at the team level to produce software that has value but the Enterprise is driven by financial considerations to fund, extract that value and report accurately along the way.

In the SAFe 4.0 Big Picture3, which illustrates the SAFe framework, the Portfolio level is well articulated and includes Strategic Themes and the constructs of Value Streams that are budgeted or funded. Epics are represented as children of Strategic Themes that guide Value Streams toward the larger aims of the Portfolio.
Consequently early budget estimates, good ones at that, are important to the Enterprise in order to decide on funding priorities and trigger strategic and tactical initiatives. But if Epics at the top are not suitable for early estimation and you cannot bottom-up aggregate, how do you estimate or budget at all?

Estimating Early Means Uncertainty

Let’s assume an existing organization, say a large healthcare insurer, has recently acquired a smaller, complementary company. Both company’s systems have to work together in the first few years to give the combined company time to either consolidate, merge or sunset the systems. Both companies employ Agile methods so it is decided to launch a strategic Agile initiative to create application program interfaces (APIs) that will make the two systems function as one. This has great value for the organization.

Let’s assume for our example that an integration working group made up of representatives of the two companies presents a high-level design outlining the, say, thirteen API’s presumed needed. Executive managements then asks for budget estimates (hardware and software) and a more specific schedule to begin the approval process.

If the organization, through their annual planning process, has already allocated or budgeted a total overall IT spend with some software component then the question is how much to set aside for this particular initiative with little information and lots of uncertainty?

Funding Value Streams Not Projects

The 13 APIs, when delivered by the Agile teams, will provide real value to the organization. The total spend to cover all of the teams for the time period needed will be governed by the organization’s fiduciary authorities. Depending on the size and scope of the functionality needed, you could conceivable have 13 separate Agile teams each working on an API. Traditional project cost accounting is challenged by this model.

In the SAFe® 4.0 framework, strategies of Lean-Agile Budgeting5 are described to address these challenges and the tensions discussed above. The takeaway from the strategies are simple, continue the fiduciary authorities’ traditional role of overall budgeting and spend reporting while empowering the Agile Teams to own content creation using the organizing construct of one or more Value Streams.

The Agile Teams, and implicitly the Agile method, are trusted to build the right things on a day-to-day, week-to-week basis within an overall approved budget. The traditional project cost-accounting methods, that seek command and control assurance, are replaced by a dynamic budgeting5 approach within the Value Stream.

Going back to our example, the 13 APIs could have a natural affinity or grouping and drive the association of 3 separate Value Streams as illustrated in Figure 4.

Figure 4: Value Stream Example

Value Stream Example

Each of these Value Streams would be funded from the annual allocated software spend, by the fiduciary authorities but how big do you make the allocation for API Group 2?

Anchoring Reality to Functionality

At this point the Integration workgroup has only two choices: Estimate by experience or estimate by functionality.

Estimating by experience can work if the right set of circumstances occur. The estimators involved are experts in the proposed work, there is a rich history of prior work where analogy analysis could be made, re-estimation is done by the same group and the technology is familiar and stable. When these factors do not exist, risk rises as to the quality and goodness of the estimate and future estimates.

Estimating by functionality means quantifying the proposed work using industry standard sizing methods and leveraging parametric or model based estimating4. This approach leverages historical repositories of industry-similar analogous projects to create estimates that include success vs failure probabilities (risk) profiles. The organization is borrowing the past experience of others to help them predict their future. When this method is used it increases confidence because of the statistical and mathematical nature of the process. The process is suitable for internal adoption as a repeatable and tunable method. Management overhead costs do increase when this method is adopted.

Whatever method an organization chooses, it should always be considered a starting point and a work-in process number and not memorialized.

Budgeting for Value

The answer to the question, “How do I calculate estimates for Agile budget deliverables this year?” is to define the value (stream) desired and estimate using your method of choice to define the portion of the overall software spend required.

As the budget is spent, within this API Group 2 Value Stream’s allocation, multiple deliverables (Releases) would be created and their individual allocations dynamically adjusted, as needed, by the team as content (Epics and derived user stories) are elaborated, understood and converted into working software.

Figure 5: Fund Value Streams not Projects or Releases

Fund Value Streams

One or more Releases will be created and shipped supporting the expense or capitalize decision and the dynamic budget changes within each release activity updates the overall budget, governed by the fiduciary authorities.

Conclusion

This lean-Agile budgeting approach relieves the organization from using traditional, command and control project cost accounting methods, which are challenged by the Agile method. This approach allows the fiduciary authorities to own what they should, the overall software spend, divided by value streams at the same time the content authorities, the Agile teams, own the day-to-day, week-to-week spending. This is a big step away from the past for many organizations but a good step forward to a more Agile organization.

Sources:
1. FASB http://www.fasb.org/summary/stsum86.shtml ; http://www.gasb.org/cs/ContentServer?c=Document_C&pagename=FASB%2FDocument_C%2FDocumentPage&cid=1176156442651;
2. Scaled Agile Framework, http://scaledAgileframework.com/glossary/#P
3. SAFe 4.0 Big Picture, http://scaledAgileframework.com/
4. International Society of Parametric Analysts, Parametric Estimating Handbook, http://www.galorath.com/images/uploads/ISPA_PEH_4th_ed_Final.pdf
5. SAFe® 4.0 Lean-Agile Budgeting, http://scaledAgileframework.com/budgets/

 

Download this report here.

Written by Default at 05:00

Who is DCG Software Value?

While we've changed our name, we're still the same company - just with a clearer mission and vision for the future. So, we've decided that now is a good time to talk about who we are here at DCG (and why we exist).

The Short Answer

DCG Software Value is a global provider of software analytics, software quality management and Agile support services.

The Long Answer

Since opening our doors in 1994, we have earned and maintained a reputation in the industry for our ability to help companies achieve their IT-related goals – and for our knowledge of how to do so quickly and effectively.

Our mission is to help IT and the business collectively visualize and discuss the value of software development. This leads to better decision making and resource management, ultimately improving a company’s bottom line. Via quantifiable changes in software development, we position IT organizations for high quality, on-time and on-budget delivery of software through all phases of the development lifecycle.

How We Can Help You

Yes, we provide software analytics, software quality management and Agile support services, but what does that mean exactly? Well, our tagline is "Measure. Optimize. Deliver.," which is also an easy way to explain what we can do for you.

  • Our Software Analytics services measure your development process and deliverables to provide you with the insight you need to identify areas of improvement and track your progress over time.
  • Our Software Quality Management services optimize your software quality through the use of proven models and advanced code and testing practices that are tailored for your organization.
  • Our Agile support services have been developed as a result of years of experience in working with clients across industries on Agile-related initiatives. We can help with initiatives to start or improve current Agile or Scaled Agile Framework® (SAFe®) implementations. In short, we help you to effectively and efficiently deliver your software.

What Sets Us Apart?

We've been in this business for more than 20 years, and as a result we have years of proven experience, ready-to-use templates/artifacts and a ability to adapt to an ever-changing marketplace.

We follow an Agile consulting model, allowing for an engagement’s focus to change as necessary. We also believe in Centers of Excellence, fully packaged and successfully tested solutions to address common software issues that plague organizations. We implement them using our Build, Operate, Transfer (BOT) implementation model. We build the CoE framework, and then we operate the CoE until an organization is ready to make the transition to run the established CoE.

Ultimately, we believe that software is a major contributor to the success of the business, and we want to see our clients succeed. We'll do what it takes to help you achieve your goals.

Questions? Leave a comment!

 

Written by Default at 05:00

Agile Competency Development

Mike HarrisOne of the 12 principles of Agile Manifesto states: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Most often this is taken as a purely technical injunction e.g. servers, tools, etc. However, there is an important dimension of human motivation that is not directly addressed in any of the Agile methodologies or in many of the actual practices: Career progression and, more simply, pay.

Historically, companies addressed this issue via a matrix structure with tiers of seniority and columns of capability. Career (and pay) progression involved moving up the tiers of seniority, one by one, in a single column of capability (e.g. junior tester to senior tester to team lead) until the capability columns merged at certain points (e.g. head of testing promoted to head of all development).

For good reasons, Agile implementations have disrupted the traditional organizational certainty by introducing roles that significantly improve software development value delivery and enhance the working experience of the participants. Agile implementations have also flattened or removed hierarchies (e.g. people can change roles from junior tester to Scrum Master to senior tester), removed whole functions (e.g. the Project Management Office), challenged managers to become “servant-leaders,” and encouraged individuals to broaden their capabilities across several of the old functional boundaries.

In many cases, organizations are “force-fitting” the new Agile roles to the existing seniority-capability (grade-pay) matrix. Transitioning between different Agile roles as its champions envisage becomes challenging. When niggling thoughts about absolute and relative pay and grade levels get in the way of autonomy, mastery and purpose, Agile implementations are doomed to failure in the long run.

So what’s the answer? We think we have one – and we’re excited to share it. Learn more here.


Mike Harris
DCG President & CEO

 

 

Written by Michael D. Harris at 05:00
Categories :

The Costly Cost Obsession

Alan CameronThe obsession with cost control rather than value delivered, in both government and companies, is driving me mad – because it’s so 20th century and backward-looking. It’s time to put the customer or citizen first.

Cost-Cutting Now Won't Balance the Books

Recently I heard on the radio that suicides amongst UK young offenders remain at unacceptable levels, and we understand too that recidivism is high amongst offenders in this age group. The Prison Service, like so many others, is being asked to make cuts so that the government can balance its budget, but that means that prisoners aren’t adequately supervised, nor is their criminal behaviour addressed.

The lack of systems thinking is, I don’t hesitate to say, criminal. The result of cost-cutting leads to no change in recidivism and the long-term effect is an increase in our already high prison population, and an increase in costs. In turn, this spreads supervision more thinly and suicide rates don’t fall.

At a small and large society level, unnecessary deaths are tragic failures of management, and failing to turn young offenders into useful citizens not only increases the costs of continuing to incarcerate them, it loses the economic value of having these people usefully employed.

The value of the positive is ignored in the downward spiral of cost cutting that actually leads to an increase in costs in the medium- to long-term while, negatively affecting productive income generation. There is obviously a balance to be drawn – crime will always be there – but, like a successful fraud investigation system, success can be measured in a reduction in convictions as compliance improves and longer-term savings are generated.

A value-driven spiral needs to be primed, but the result is positive. As recidivism is reduced, staff are freed up to provide better supervision of and guidance to those with potential suicide risks, repeat offenders behaviour is changed and they start to add to society. Costs go down and tax generated from employment goes up. Instead we “cut” costs and build more prisons.

Short-Termism Damages Share Value

Let’s turn to industry. When profits don’t meet targets, the dead hand of hierarchical management and finance tends to decree, “No training,” or “No travel,” or “No process improvements.” You choose, and then let’s look for “Efficiency Savings.”

Examples abound. One company I know of provides support for purchasing for customers. 60% of these orders are single line items, and so the support is being removed from everyone. However, a small piece of analysis shows that the largest clients with the biggest global spread make up much of the other 40%. Some of their orders may be 100 line items, but the support has been removed so the end operatives have to take longer to complete orders for the highest value clients. So costs have been cut to help now, but some global clients simply won’t renew their contracts if deliveries of products are delayed.

The company looks only at costs and not at the value of the complex clients. Great for this quarter, but not so good in a few years. Revenue and profit will fall, but by then all the executives will have changed, and the next lot will start another round of frantic cost-cutting.

Similarly, a potential client, which is supposed to be Agile in all it does, has had to postpone a value-add process improvement in order that costs can be controlled. The hierarchical management is driven by 20th century share value behaviours at the expense of stable, predictable projects, delighted clients and future growth.

Contrast that with another client who can see that spending a few thousand pounds on a robust estimating service can assist with the control of projects worth millions. They see the value of what’s traditionally seen as an overhead, i.e. discretionary spending.

Shifting the Mindset

As Steve Denning pointed out in his keynote speech to the Agile Business Conference in London, cost-cutting is an inward looking view of what matters most to organisations, and as such, the only people ever satisfied are the inner circle who take the short-term gains it delivers. Executives paid in share options and politicians, wanting to make themselves look good, cling to the view that the customer/citizen doesn’t matter.

Contrast that with a customer-centric view where delighting the client matters most, where the value of actions is thought through and implemented. Self -organising teams manage their training to ensure that skills are optimised, and process improvements are continuous and focused on delivery for the client. Finance takes a client-centric view with a greater appreciation of how development teams deliver value and they support those activities.

In government, local control is real and targets are based on outcomes and not cost alone. Teams are multi-disciplinary and the silo boundaries between departments are porous. Vulnerable adults in prison are assessed to see if that is an appropriate place for them to be. Prison is not seen as primarily a place of punishment, but rather one where success comes from reducing re-offending and making released prisoners valuable to society. Teams address basic issues such as illiteracy, and social interactions to break cycles of behaviour. The cost is balanced against the value and not the need to cut for the sake of someone’s ego.

We firmly believe that the most successful software development comes from Agile teams focussed on adding value to clients. It is demonstrably true there and also in government.

It’s time to leave the 20th century and to put the customer/ citizen in the middle of all our thinking and to only do something if it adds value to those people. If you can’t answer the “What’s the value of this?” question, then don’t do it.

Written by Alan Cameron at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!