Scrum Methodology

Results of an Agile Assessment

Posted by admin under Agile and Scrum, Agile Assessment, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

We recently set a team of consultants from my company to conduct a formal assessment of a medium sized financial firm’s an Agile capabilities. I’d like to share thew approach here. The team went on site to conduct interviews and observations in 5 areas –

• Value delivery
• Agile engineering
• Project Management
• Product management
• Environment and Organizational Culture

Also, the investigation took input on the demographics of the individual project being examined, the stakeholders involved and the competitive/regulatory environment in which the organization as a whole operates. Understanding the context in which an organization operates is crucial to understanding the optimal level of Agility, and thus, the plan of action.

Understanding the goals of the organization is particularly important. Not every axis needs to be top-ranked to achieve the company’s goals. In fact, on this particular assessment we found that only one needed urgent attention – Project Management. I’ll provide details in another post.

Technical Debt – The High Cost of Change

Posted by admin under Scrum Basics, Scrum Discussion, Scrum Transitions

My consultants and indeed my own software development teams often grapple with technical debt. often Products carry technical debt when they are difficult or risky to change. Technical debt isn’t listed on your balance sheet, yet it can destroy your business.  It’s important to understand where Tech Debt comes from in order to effectively address it:

• A common reason for bringing technical debt into a code base comes from the business stakeholders. Assuming they have a reasonable understanding of the consequences, the business might consider getting something released sooner is of more value than avoiding technical debt. They should understand the “interest” payment that will be incurred if they insist on this path! In many cases, businesses stakeholders simply don’t understand the ramifications of what they are asking for, nor do they fully grasp the concept of. They make decisions solely on immediate business pressures rather than taking a more long-term view.
• Technical debt also comes in the form of poorly constructed, inflexible software. This may come about when functions or interfaces are hard-coded, and as such, are difficult to change.
• Lack of documentation is another reason for technical debt, both in the code itself and in the external documentation. When documentation is poor, new team members who want to modify the code in the future have a hard time coming up to speed on the code which that slows development.

Enlightened management can have a real impact on mitigating the addition of technical debt and in paying it down as you go, by constant refactoring. There is an interesting webinar on this topic available here.

Strategic Vision and Scrum

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

When organizations adopt an agile approach to development like Scrum there is so much focus on the iterative nature of agile development that long range vision and strategic product design can get lost. Jimi Fosdick is doing a webinar on November 28 to discuss the need to include long term product vision, coherent user experience and User Centered design and architecture along with specific best practices for achieving a coherent product that delights users.

Topics will include:
• Discussion of Product Vision and approaches to crafting a compelling overall vision for products
• Discussion of User-Centered/Value-Driven design and approaches to incorporating user experience (UX) and software architecture early in the development process
• Explanation of the pitfalls of a lack of vision and so-called “hybrid” models for incorporating UX and architecture into Scrum Projects

You can register for the webinar here

Agile and PPM – Q&A

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

The webinar, “A Marriage Made in Heaven: Agile and Project Portfolio Management,” took place on October 27. I (David Parker) hosted, along with Russ King, Vice President, Product Development, Results Positive, Inc. and Caleb Brown, Systems Engineer at CollabNet. During this session, we explored the benefits of marrying Agile Project Management and PPM and we did a live demo showing this using HP’s PPM solution and CollabNet’s ScrumWorks Pro to demonstrate the powerful capabilities of managing a resource constrained project portfolio.

If you’re interested, you can watch the recording and download my slides. Here, I post some of the questions and our answers:

Q: How feasible is Agile on Projects & Programs?
A: Agile is typically thought of in the context of individual projects. Companies sometimes fail to scale that paradigm to a program level, where the program is a superset of multiple projects, each running its own lifecycle and release plan. The trick is to weave those separate lines of development (projects) into a coherent and seamless deliverable (program). The complexity comes in gathering meaningful metrics and planning releases that thread the elements together. This is exceedingly difficult to do manually. CollabNet’s ScrumWorks Pro is a tool that can make this manageable. It supports the planning of complex releases that weave in multiple development threads.

Q: Will this process will be feasible for maintenance related projects (Incident handling, less than 8 hours development works, etc.,)?
A: From the PPM perspective, an individual defect is not in and of itself a project and as such, would not be tracked. What might be tracked is a larger group of maintenance items in the form of an Epic. From an Agile perspective, a bug report or defect is just another piece of deliverable business value, like a User Story or any other Product Backlog Item. From a bug report, the product owner and team would create a Product Backlog Item (PBI), along with success criteria (definition of done). It is prioritized against all of the other Product Backlog Item by the product owner. Again, multiple bugs/defects are often grouped in an Epic.

Q: It seems the PPM is geared toward a waterfall process. It appears there is only visibility into the Development phase, but with agile, you could potentially address all phases within a single sprint. Is that just because of the way this implementation was set up or is it there isn’t a true marriage of the agile within PPM?
A: PPM in this scenario is focused on evaluating the ROI of different projects and deciding where to make investments. Agile is focused on execution of the projects that are chosen. That said, the scenario we propose makes the entire organization more Agile, in that the feedback loop is instantaneous. This allows those that are making the investment decisions to adapt and make course corrections that are indicated by that feedback loop. The integration gives all team members the ability to work in a more Agile fashion, and gives Stakeholders and Project managers the ability to benefit from the faster feedback and data generated by the team working this way.

Q: Can the tasks in Scrum WorksPro be connected to tasks, timelines in Source forge?
A: Not with Sourceforge. However this is possible with Collabnet Teamforge, the current commercial version of Sourceforge.

Q: Can you clarify what part of Agile PPM can be done in scrum works pro without need for HP PPM?
A: ScrumWorks Pro is focused on project execution and project management. As such ScrumWorks does a number of things not accomplished in HP PPM. These include PBI tracking and prioritization, Task management sprint planning, release planning, team velocity, forecasting, and many other functions related to the management of an Agile project.

Q: So are you proposing (in the demo) to combine a phase/waterfall planning and design phase, but then execute in an agile framework?
A: Combining HP PPM and ScrumWorks Pro adds to the agility of the entire organization. Feedback loops between the development team and the PMO are enhanced allowing the PMO to make course corrections required. I would not say that as a result the entire enterprise has become agile – only that they’ve become more agile. Generally, we do not see many organizations that practice a pure version of ANY methodology –be it Agile or otherwise. The reality is that organizations have a mix of methodologies, like Scrum, Kanban, Waterfall, hybrids, etc. Different teams in large organizations will often build software differently, so the challenge is to roll up the data from those disparate teams. Despite their differences, there are a number of common metrics you can track regardless of project type. These include actual cost versus budgeted cost, scope change, personnel/resource change, delivery dates, and others. Tools like ScrumWorks and HP PPM do a good job in tracking these kinds of numbers.

Q: Continuing from the first question, from a portfolio perspective, having “”open-ended”" project budgets within the Agile/SDLC process is not in the best interest of my customer. How does budget planning and Agile development work together while still having some control over costs?
A: Project prioritization and the associated budgeting/funding are is under the purview of the PPM tools. The agile project management tool tracks the amount of time individuals spend on the project. The integration between the HP PPM tool and the Agile Project Management tool, allows you to easily compare budgets against actuals.

Q: For the Forecast report in SWP, if new backlog items are added during the sprint, does that add to the top or bottom of the bar? Also, how does the Project Portfolio Management tool fit into the larger Enterprise Architecture discipline?
A: It depends on what report you are looking at. In the forecast report, added backlog item appears on the bottom of the report and impacts the forecasted delivery date.

The “Burn-Up” Report shows the relationship between work completed per iteration (sprint velocity) and project scope change. The forecast feature extrapolates the rate work gets done against the rate of scope change to provide an empirical release completion forecast for more accurate release planning.

Q: In agile, what are the differences between being adaptive to late changes in requirements within a sprint and scope change?
A: Scope change refers to any added or subtracted scope, typically measured in some form of relative effort unit like Story Points. As such, scope may be added as a team discovers more about an existing requirement. In other words, if the team finds out that a requirement is more complex than was originally envisioned, they may re-estimate the number of story points and this might add scope to a sprint. The opposite could also be true. Whether this occurs because of a discovery inside a sprint or outside of it doesn’t change the nature of how it is tracked or reported upon.

Q: When a committed backlog item could not be completed in a sprint, naturally it holds the top most priority in the following sprint. How does ScrumWorks helps in tracking this item from the beginning to end?
A: An unfinished PBI may or may not be a high enough priority in a future sprint. The determination is made by the product owners. In any event, any activity against that PBI is tracked. Tasks completed that relate to that PBI are tracked, as are those that were uncompleted.

Q: What certification do CollabNet-trained scrum masters receive?
A: Those who attend one of our Certified ScrumMaster or Certified Product Owner training are eligible to take the exam deliver by the Scrum Alliance. It should be noted that CollabNet is one of the leaders in ScrumMaster product Owner training. We have more Certified Scrum Trainers on staff than any other vendor, and we’ve trained more than 12,000 ScrumMasters.

Q: If an organization wants to be able to report a metric of time to resolution for individual PBIs, what settings are available in this integration to include/exclude a PBI from the current active lists so that a countdown starts appropriately?
A: Forecast reports in ScrumWorks can be filtered on any number of aspects, allowing a user to deliver estimates on individual tasks, Stories, Epics or Themes. By the way, you can try out ScrumWorks Pro either in a hosted environment or as a free download.

Estimating Earned Business Value on Agile Projects

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

A pattern I’ve noticed is that Scrum projects are typically managed informally, with the only measures used being various velocity metrics and burndown charts. This may be an issue. Many project managers and executives resist scrum because these only measure the speed of delivery, not the project’s cost or the business value it generates. One of the major differences between traditional and agile projects is that traditional projects focus on delivering software that satisfies requirements, while agile projects focus on maximizing ROI through continuous feedback and re-planning.

This is where Earned Business Value calculations come in. It fits well with Agile projects, since the focus of agile projects is on business value rather than conformance to requirements (outcomes over outputs). In many cases, EVM metrics are easier to calculate and understand in agile environments than in traditional ones. There are three key management measures – Cost Performance Index (CPI), Schedule Performance Index (SPI), and Earned Business Value (EBV) – that provide information to help manage an agile project from and ROI perspective.

There is a solid white paper on this topic at .

Intro to Agile

Posted by admin under Agile and Scrum, Agile Principles, Scrum Basics, Scrum Transitions

There is an interesting article on the Scrum Alliance Website entitled “Negotiating Scrum Through a Waterfall”. Phil Southward, CSM, CSP details the considerations development teams must face in a transition. Is it all or nothing, or can these two development methods coexist? Does it depend upon the project or how willing the organization is willing to embrace new methodologies? http://www.scrumalliance.org/articles/189-negotiating-scrum-through-a-waterfall

Phil’s intent in writing this article is not to pit the two methodologies against each other. Although his preference leans toward agile, he realizes that going full agile is sometimes not possible, particularly in the beginning of the transition. Rather his intent is to explore how Scrum can fit into a waterfall environment when the organization is unable, or unwilling to implement Scrum completely.

If you are interested in this discussion and want to explore the differences of Scrum and Waterfall in more detail – check out this great whitepaper “ Introduction to Agile Software Development” written by Victor Szalvay, CollabNet CTO and CST. It’s an excellent primer for those new to Scrum and agile. Szalvay discusses agile’s origins, its basic concepts, and how it has revolutionized the way software is developed.

http://www.danube.com/system/files/CollabNet_IntroToAgile_wp_0710.pdf/?=scrummethodology

The Agile Manifesto and Twelve Principles

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

In February 2001 seventeen software developers met at a ski resort in Snowbird, Utah to do some skiing while spending time reflecting on what defined the core principles of agile software development methods. Although they had unique experience and expectations, they united with the objective to uncover better ways of developing software and to help others to do the same. In their discussions they found consensus around four main values, which we know now today as the “Agile Manifesto”. Most of us practicing agile have probably memorized these 4 guiding values – but it’s always good to periodically come back to them and reflect on what they mean to us today:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

Supplementing the Manifesto, the Twelve Principles further describe what it means to be Agile. As I read through these I thought of how software development has changed since 2001 – especially for enterprises with globally distributed software development teams. As you read through these principles – which ones do you find the most important or the most challenging to adhere to? If you were to rewrite any of the principles which one(s) would it be and what would it be?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’
competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Daily Scrum; It’s a Good Habit to Make

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Transitions

When you think of the word “habit” what do you think of? In the dictionary, there are several distinctly different meanings for “habit” such as:
1. A customary practice or use
2. An acquired behavior pattern regularly followed until it has become almost involuntary
3. An addiction, especially to narcotics
4. A dominant or regular disposition or tendency; prevailing character or quality

We tend to think of “good” habits or “bad” habits. When the behavior we are repeating results in positive circumstances, it is “good”. When it leads to negative results, addictions etc. it is “bad”.
The “daily scrum” is the heartbeat of scrum and is a “good habit”. Tamara Sulaiman, a Certified Scrum Trainer, in her blog post titled “Techniques for Improving Your Daily Scrum; when Your Daily Scrum isn’t Daily” says, “The daily scrum is one of the most valuable practices that any team can use.” The purpose of the daily scrum is to increase the team’s communication and focus by answering 3 questions, “What have I accomplished since the last meeting? What do I plan to do for the next meeting? What impediments are in my way? “ When teams don’t huddle daily, they risk losing the communication, focus and momentum of a team necessary to build the right product with the appropriate quality on time. Oftentimes, teams will have excuses for avoiding the daily scrum or stand up meetings. I’m sure you will be familiar with many of the excuses Tamara talks about. The daily scrum, however, makes teams more successful because it is the smallest, tightest feedback loop built into the Scrum framework. Think of it like brushing your teeth or exercising daily– it’s a good daily habit to make and will pay off in the long haul.

Can CSMs and PMPs Get Along?

Posted by admin under Scrum Discussion, Scrum Transitions

A hot topic in the Scrum community of late has been whether the agile framework is compatible with traditional project management. Lately, an intellectual curiosity about the other has materialized in both camps. That is, after years of assuming they were on opposite sides of the fence, both groups are trying to determine what they can learn from each other.

If you’re a traditional project manager who wants to learn more about Scrum and how it could improve processes at your organization, then you should take a look at an article on Agile Journal called “An Agile PM Isn’t What You Think: Where Does Traditional Project Management Fit into an Agile Project with Scrum?” The article’s author, Jimi Fosdick, who is both a Certified Scrum Trainer and a Project Management Professional, lays out what’s at stake in Scrum and proceeds to illuminate how its minimal framework actually addresses the job functions of traditional management roles. If you’re thinking through these issues, then Fosdick’s article will be a valuable read!

Advice for Agile Adoption

Posted by admin under Agile and Scrum, Scrum Transitions

One of the most common refrains in the agile and Scrum industry is that implementing those new processes is both hard and disruptive. By now, no one should be surprised to find out that there’s pain in changing—especially in situations in which groups of people are asked to dramatically revise the way they’ve always worked. But in an InfoQ story by Vikas Hazrati, Dave Nicolette reveals his experiences with Scrum and agile adoption, which suggest that a successful transformation is even harder than we all thought.

Many consider the creation of a single, functioning Scrum pilot team to be the big hump to get over during initial implementation. But according to Nicolette, that doesn’t necessarily mean an organization is out of the woods. As he explains, it’s not uncommon for a pilot team to be broken up to begin additional teams, which can often undermine the chemistry of the original team and fail to translate throughout the organization. In other scenarios, a pilot team may simply revert to old habits as soon as an on-site consultant leaves.

In Nicolette’s view, the two main reasons that pilots fail to stick at an organization are:

• “Local process optimization – The pilot teams were separate from rest of the organization. They were working in isolation from rest of the organization and as soon as the pilot was over that ripple in the ocean faded away. The changes were carried on too much at a local level to cause any amount of friction in rest of the organization.
• “Insensitivity to emotional factors – The consultants ignored the support of individuals and departments who would have been instrumental in the sustained success of the effort. As a result of this as soon as the consultants left, these support groups rallied together to get into the earlier way of working.”

That’s some good food for thought—and possibly a way to help your pilot team lead the entire organization toward a successful Scrum or agile adoption.