Tag: Agile

There is a notion that Agile projects do not need project managers. I think every project needs to be managed and therefore there is a project management role. Whether that means there is person designated as PM is another thing. PM as a role can be shared. The important thing is to make sure that planning, monitoring, controlling, communication and stake holder management are being done well with the right degree of formality and discipline.

In Agile software development projects the team has all the means needed to control their work and to easily deliver metrics that give management above the project level a clear sense of progress and status.  They follow a disciplined approach that embeds quality control into their work.

There is a feature set that has been described and a very concrete set of accomplishments as the team completes the features.  Clearly someone has planned and decided on the feature set and the sequence among the features.

As the team assesses the work they apply a “burn rate” derived from work on past, similar projects – analogous or parametric estimating. As they burn through the feature set they can compare actual rates to expected to measure productivity and report accomplishments.

A Scrum Master or equivalent plays part of the PM role acting as communicator, making sure issues are addressed and buffering the team from interruptions and other drains on their productivity.

Additionally, most if not all Agile projects are embedded in projects and programs, for example, new product development, and business process improvement involving application software development.

These higher order projects are generally more complex than the typical Agile software development project and must be managed in a more traditional way, with a designated PM, while encouraging the Agile approach on those sub-projects where it is appropriate.

In the end whether Agile projects need a PM is not worth arguing.  All projects need project management. How it is applied can vary from situation to situation.

To be successful in Agile environments (and in fact to do well in most environments) PMs must first favor people over process and avoid a command and control approach, relying on and promoting a shared vision and collaboration, including healthy conflict and its resolution.  The objective is to cultivate and reinforce self-managing teams in which the team members, considered peers of the PM, make decisions and perform many project management roles.

The project management role includes a leadership component, which when done well leads to the team thinking that they did the work and the leadership themselves.

Don’t forget to leave your comments below.

While I have reviewed some practices to consider when changing methodologies from traditional waterfall approaches to agile ones in Avoiding Speed Bumps when Adopting Agile Practices the input from a participant at one of the roundtable discussions at this year’s ProjectWorld Toronto inspired a few more.

The attendee indicated that his organization had embraced agile methods on a specific technology project but the issues and cost overruns they experienced stymied further attempts to adopt agile practices.

Further discussion of the specifics of this case study yielded some more lessons.

1. Start simple and expand complexity progressively (also known as “success begets success”) – in most organizations where agile methods have “stuck”. A pilot was done using a small (though highly visible) project that satisfied the 3 C’s of agile – collocation, collaboration & (open) communication.
2. Leverage coaching assistance – It is very hard to manage your first agile project while simultaneously coaching the overall project organization (customer, stakeholders & team) through this process and philosophy change. If you happen to be the sole agile evangelist within your company, it may be worth justifying the costs of an outside coach to focus on the change aspects.
3. Trust is mandatory – As with any other strategic change, commitment to the change means more than just focusing on the expected benefits while giving lip service to the costs. As I previously wrote in Trust – a critical success factor for successful agile projects, a lack of trust between key roles on agile projects can sometimes result in worse outcomes than on traditionally managed ones.
4. Identify “appropriate usage” criteria for agile methods – Not all projects lend themselves to the use of agile approaches (just as not all projects can be successfully managed using waterfall approaches). Developing checklists or similar tools to help project managers decide whether a purely agile, a purely waterfall or a hybrid approach is best suited to their specific projects will help to reduce “square peg in round hole” situations.
5. Don’t get hung up on specific methodologies – unless the nature of your projects exactly fits a particular agile methodology, it is better to focus on adopting (and adapting) principles rather than to blindly follow an off-the-shelf set of implementation practices. Fanaticism towards any specific agile “religion” is hardly likely to reward you with converts.

Through committed executive sponsorship, appropriate staffing and a “walk before you run” implementation approach, you can reduce the likelihood that an agile initiative will go over the waterfall!

Don’t forget to leave your comments below. 

There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Often she was disappointed in her quest and shouts “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—then sort of throwing the software “over the wall” for feedback.

Quite often they are under the gun to deliver a smorgasbord of features. Almost as if no one knows what the customer needs, so they shotgun scatter solutions hoping to hit their needs. Fingers crossed. While this may be somewhat successful, it also results in delivering low value features that dilute the focus of the team and increase product development costs.

Wouldn’t it be wonderful if we could focus entirely on “The Beef” in application development? Spending most of our energy focused on delivering high-value and high-need solutions to our customers. Cutting through the clutter of disappointment and ambiguity and simply working on what matters most?

While it sounds like a fairy tale, the agile methods aspire to just this purpose. But it’s not easy to achieve and the effective Agile Project Manager plays a wonderful role in this quest. In this post, I want to share some ideas on how to focus the team towards value delivery.

A Prioritized Backlog!

One of the first mechanisms that drive value is the Product Backlog—the simple prioritized list that drives what agile teams are building. Every team should be laser focused on prioritizing their backlogs in 1..n order. There can’t be three or four priority one features—there can be only one; then two, three, and so on.

Trust me; your customers and stakeholders will want to play infinite games with priority. I’ve seen cases where they have groupings in a spreadsheet that are prioritized and then sub-features broken out within each of them. They’ll insist that they can’t decompose the value out any further as they try to overload priority. This (1a, 1b,..1z) approach allows them to escape true prioritization and selection, also indicating their innate inability to make hard choices regarding what’s truly most important. Don’t let them do that!

An effective product backlog is always in linear and priority order. The team will always deliver the highest priority features first. They will work on them first, finish them first, ensuring the customer is engaged as appropriate.

And since the customer is the final arbiter of priority, they shouldn’t really complain about this approach. It’s just that we’ve historically allowed them to give us large lists of features without making this distinction—so they’ve gotten a bit lazy.

When encouraged (forced) to prioritize, I’ve never seen a stakeholder who couldn’t do it.

Customer-Driven Value

Prioritization can also be driven by perceived value—change that to should be driven. One technique used by many agile teams is the notion of Value Poker. It’s a variation of the popular Planning Poker technique that is used for User Story size estimation. But instead of determining size of stories in story points, we use Value Points as the determinant.

In this case you use a deck of cards labeled from 1-10, one being the lowest value and ten the highest. For each User Story or Theme of stories you ask a group of various customers and stakeholders to ‘vote’ on their view to value of the Story. You take a round-robin approach discussing the ‘why’ behind the highest and lowest values—letting the team express their views towards value nuance.

Once the discussion is over, you re-vote and re-discuss until you narrow the value as much as possible. Sometimes you gain agreement across the team. Sometimes you simply get a range.

You might even compartmentalize values from the different perspectives of the team. For example, the quality and testing folks’ might value a particular story as a five, while the business folks’ value it as a three and development or technology folks’ as a one. All of their valuations provide important data as to how you cross-functionally value the feature.

This logic might be applied to multiple stakeholders as well. For example, the North American stakeholders might value a feature at six, while the EMEA stakeholders think it only a three. In all of these cases, discussing VALUE as a distinct attribute helps the team in prioritizing and in deciding how much fit & finish to apply to individual features.

A Variation

 A truly effective variation on the Value Poker technique is to give every voting or contributing partner a ‘pool’ of funding to spend as part of their voting. So not only are they voting on a value, but they have to invest a portion of a fixed pool of dollars on the feature as well.

Quite often monopoly money or a similar fun equivalent is used for this purpose.  Let’s say everyone gets $5,000 to spend on their features as we play priority poker. In one particular case, a business stakeholder votes a nine for a feature.

In order to emphasize the importance, they put up $1,500 on the feature or about 30% of their available funds. In fact, they only spend their pool against a total of seven features. While they continue to prioritize subsequent features, they’ve clearly communicated their views towards value. In fact, that $1,500 feature ends up being the #1 priority with a total value pool of $12,000 across the entire voting team OR 25% of the available pool.

So here’s an interesting question. If you’re implementing this feature, what does #1 Priority convey vs. #1 Priority AND 25% of the value pool? From my perspective, there’s a large difference. This feature is a much more significant portion of the value and requires particular care in execution. I hope you see the difference.

Minimal Marketable Feature (MMF)

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be valuated by the customer. Earlier I spoke in terms of a theme of stories. This is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic level, it simplifies your prioritization. It also has more meaning from the customers’ perspective.

A variation on this theme (pun intended) is the Minimal Marketable Feature or MMF. This concept originates in the Kanban and Lean spaces. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF is larger than a theme. It could be equivalent to a user story epic and require several sprints to complete. However, once complete, the team will usually physically deliver the MMF to the customer—for example, pushing it into the production environment.

Tracking Value

One of the wonderful additions to your tool-set as an Agile Project Manager is burning down (or up) the value of stories, themes, or MMFs. You’ll want to setup a burndown chart in a well visited location that burns down team delivered value. As with all burndown charts you’ll want to keep everyone’s eyes on progress and interacting with the team over progress and flow.

You’ll want to calculate total value for a release or project. Then setup your burndown on an iteration-by-iteration basis.

If you’re getting healthy agile behavior within your team, you’ll see value being delivered in a front-loaded fashion. You should also see healthy done-ness and quality attributes as these high-value features are delivered. In fact, I usually expect teams to factor in value as part of their overall quality and testing strategies.

Wrapping Up

Agile Project Managers don’t just care about by-rote execution of tasks or stories. No! Instead they focus their teams on a multi-faceted and nuanced view towards customer, value-driven execution.

Not only are they hoping to deliver value first, but they’re also hoping that by doing so, the customer may achieve a “good enough” view towards incrementally delivered product increments and allow the team to stop the project earlier than planned.

Stopping after delivering the features and functionality that truly matters the most to them. Sort of gaining their value and then moving onto their next highest value-driven project. It’s this sort of value-trimming that can truly make an agile team stand-out from their traditional counterparts and move so much faster.

 Don’t forget to leave your comments below. 

The phrase “time is fleeting” has never had more relevance than it does in the 21st century as today’s “C-Suite” executives and their employees confront overwhelming demands on their time.

Time is as critical as money. Yet, many companies are not accustomed to allocating and investing it with the same level of care as they would with more traditional assets. Few executives “get it” that time must be managed, accounted for and invested in ways that maximize return. This is often easier said than done as companies seldom possess the right processes and infrastructure to make the most of time resources.

They often confuse the core business process of time-resource allocation with simple “timesheets” or “time management calendars.” This is as dangerous as confusing a simple check register with a company’s capital investment strategy.

To allocate and manage any resource, it must first be seen clearly and then tracked carefully. Time tracking should be a fundamental part of any business. Almost every business tracks time at some level — even if only for payroll. At the most basic level, some companies employ a simplistic, homegrown system that is based on spreadsheets.

Even companies that have fully automated time-tracking systems may fail to leverage those systems to drive profits up and/or costs down. Leveraging such systems is neither as easy nor as obvious as it seems. Some companies may understand the potential gains associated with managing time as an asset, but lack the right knowledge or tools. Many others succumb to a misinformed and needless distrust of time tracking. Still, others mistakenly believe that time tracking systems are simple, and develop or buy inadequate systems that fail to deliver real value to the entire enterprise.

An expertly developed and finely-tuned time management system can become a window into the real-time costs of any organization, especially if it provides —

• Access and a thorough understanding of costs at every level of the business — at a team level, a task level, a project level, a business unit level and a company level.
• Complete visibility into these costs for everyone in the organization who can impact them.
• Power to redeploy and shift time resource investments to optimize processes, reduce risk, thwart competition, drive revenue, and increase profits.

The benefits of such a system will make the relationship of time and money crystal clear. While identifying costs is nothing new for most companies, many experts agree that traditional cost accounting methods may not yield the right information for some of the most vital initiatives that companies undertake, such as competitive strategy formulation and execution or project portfolio management.

New ways of understanding costs, such as activity-based costing, have emerged to help companies redefine and realign their strategies. Yet these new methods are only as good as the data that feeds them—and time data is a critical input.

Identify Core Processes

To understand time tracking as a core business process, first consider that time data feeds four fundamental business functions:

• Payroll
• Billing
• Project management
• Business strategy development

It’s important to find a solution provider that addresses all of these functions. Some providers might only manage hourly time with the aim at lowering the cost of payroll by punch rounding, security lockouts, and other techniques. These packages are so well suited for managing payroll, that they are unsuitable for project management or billing automation.

Some providers focus on billing software and are great at automating billing for small companies, but they don’t do payroll or project management. And others focus on great project management but can’t do payroll or billing automation.

The ideal solution should offer the ability to automate time tracking for project management, billing, professional (i.e., salary) payroll, and increasingly, for hourly payroll. This will enable a qualitatively new function: time tracking for strategic analysis.

This will help companies better understand which of their projects generate profits. An important first step is to know whether projects are on schedule or within budget. However, this step alone is not enough. Despite project managers’ keen abilities to remain within schedule and budget constraints, all too often they find themselves out of a job when their projects, product lines or research portfolios are deemed unprofitable or excessively risky. Budgets and schedules alone won’t make a company successful. Only projects that create profits will drive success. All projects, whether internal or external, must somehow drive the company to greater profitability. If they do not, they will be cancelled.

It is critical to constantly monitor projects throughout their lifecycle in order to continue or terminate them. Two questions to ask: “How much of my project’s budgeted time has been spent?” and “How close are we to completion?” will offer some valuable information to make a decision. If you have used thirty percent of the allotted time and you are only ten percent done, that is a red flag. However, it’s better to have that red flag raised when you have spent thirty percent of your money rather than eighty percent.

The companies that manage their portfolios of internal and external projects skillfully — ensuring that all projects help the company make money — will be the companies who survive and succeed in both good times and bad. The hard truth is that no company can afford to mismanage its project portfolio. Whether that portfolio contains two or two-hundred projects, the goal remains the same: profit.

To reach this goal, companies need to be smarter about how they collect and use critical time data to evaluate project cost and performance; allocate labor and other resources; and estimate future project schedules and costs. They can reduce risk of failure by understanding the true costs of their project in real time, and by taking necessary action sooner when the chances of success are greater.

The right time data, accessible in real-time, is critical to solving project management problems.

Don’t forget to leave your comments below.

---

Curt Finch is the CEO of Journyx. Since 1996, Journyx has remained committed to helping customers intelligently invest their time and resources to achieve per-person, per-project profitability. Curt earned a Bachelor of Science degree in Computer Science from Virginia Tech in 1987.  As a software programmer fixing bugs for IBM in the early ‘90’s, Curt Finch found that tracking the time it took to fix each bug revealed the per-bug profitability. Curt knew that this concept of using time-tracking data to determine project profitability was a winning idea and something that companies were not doing – yet… Curt created the world’s first web-based timesheet application and the foundation for the current Journyx product offerings in 1997. Curt is an avid speaker and writer. Learn more about Curt at http://journyx.com/company/curtfinch.html.