Tag Archive for Scrum

Agile is Not for Everyone

Agile is Not for EveryoneThe agile manifesto was published almost 20 years ago. The publishers of the agile manifesto looked to overthrow previous project management methodologies. The agile manifesto authors cast away what they considered burdensome. They looked to eliminate contracts, plans, and documentation. Along the way, agile became the latest consultant-speak to solve any firm’s problems.

Agile has morphedOver the years Agile has morphed into CI/CD, DevOpsExtreme Programming, Kanban, Lean, SAFe and more buzzwords. The top agile methods employed by organizations include scrum (54%), scrum/XP Hybrid (10%), custom hybrid (14%), scrumban (8%), and kanban (5%).

Agile is a blanket term for a set of methodologies that emphasize collaboration within tightly-knit teams, iterative development, early delivery, continuous improvement, and the ability to respond rapidly to changing requirements. Despite these lofty goals some argue that agile has become as dogmatic as the predecessors it sought to overthrow.

Backlash against agile

Agile is a blanket termRecent signs are pointing to a possible backlash against agile. California-based IT research firm Computer Economics reports that the growth in agile development is starting to taper off. Adoption was flat year over year, and we may be closing in on the ceiling for agile.

In their report, Agile Development Adoption and Best Practices, Computer Economics found that 60% of survey respondents practiced agile development in 2019, the same amount as practiced in 2018. In 2015, only 49% practiced agile, and that figure rose steadily until 2018.

David Wagner, senior director of research for Computer Economics concluded:

Most software developers will tell you that agile is the only way to develop software … However, when requirements are fairly stable and well-understood, a more traditional development approach may be best. Also, agile works best when developers can be assigned to single projects over a longer period of time which is not always possible, especially in smaller companies.

rb-

agile might not be right for them.Computer Economics concludes that Agile is an important tool for organizations with high-level development needs, such as software and cloud providers. However, for most enterprises that do little custom development, agile might not be right for them.

Corporate IT organizations that have not already adopted Agile are expected to slow in adapting it in the future. KPMG found (PDF) that 63% of business leaders claim that the maturity of agile project management is lower than that of traditional project management.

I always like to follow the money because it leads to interesting places. Here are some factoids around Agile. The project management software market size is projected to reach $6.68 billion by 2026.

If we take these factoids together by 2026

  • MSFT is set to bring in $1.8B in project management software by 2026.
  • TEAM is set to bring in $1.7B in project management software by 2026.
    • Jira – set to bring in nearly $1.3B
    • Trello -will bring in nearly $380M

planned obsolescence trainSo following the money, it is very likely that intentional obfuscation on the part of corporate marketing machines at MSFT and TEAM to drive changes to PM methodologies in order to keep everyone on the planned obsolescence train and have to update PM and PPM software every year to match the latest agile methodology.

Stay safe out there!

Related article

 

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedInFacebook, and Twitter. Email the Bach Seat here.

Guestimating for Project Managers

Guestimating for Project ManagersSince the dawn of time, one of the questions most likely to strike fear into the heart of even seasoned project managers is, “So how much is this project going to cost?” In fact, at Brightwork says there are hieroglyphs on the wall of the tomb of the great pharaoh Khufu, depicting the pharaoh asking Vizier Hermiunu, the pyramid’s project manager, this very question about his burial pyramid and, a few walls down, a second depiction of the project manager being thrown into a nest of crocodiles in the Nile after the project overran its budget by a few thousand debens.

As evidence of how little project management progressed, Mr. Kreha relates how he sat in a questioning-techniques-in-training estimation meeting and watched an agile” project team assign “points” to “stories” in a vain attempt to estimate how much work they might get done in the next two weeks, aka the next sprint. And inevitably, a new team member would ask at some point, “so how many hours are there in a point?” Immediately, this agile novice is mocked mercilessly! “You don’t understand,” the scrum master and other developers say, “points aren’t convertible into hours or dollars. We use a Fibonacci sequence – you know, 1,2,3, 5, 8, and 13 – to estimate how much effort a story is. It has nothing to do with hours or money.”

And so we project managers are still left holding the bag for estimating projects, often early in a project’s lifecycle, and then being held accountable for them as if we were clairvoyant. What can be done?

Brightwork’s Kreha offers some hints on how to stay out of the croc pond. Start doing them, that might help:

Separate hard costs from soft costs

Separate ‘hard costs’ from soft costsWhen you’re estimating. Hard costs are things like license fees. Once you have a quote from a vendor (stall until you have one) you can be pretty confident that’s what the cost will be. Hourly labor, and time and material contracts in general, are obviously softer since you’re funding time and not deliverables per se.

For softer costs, use burn rates’ to look at low, likely, and high ranges for labor costs. For example, if you have a team of 10 with an average bill rate of $100/hour and they will be working on your project more or less full time for the next 5-6 months, you’re looking at $860k to $1M if I did the math right. Don’t get suckered into estimating hours without thinking about time, because things ALMOST ALWAYS take longer than you planned.

Use ranges wherever possible

use ‘burn rates’Early in a project, it at least helps to subliminally communicate to stakeholders that the project costs are still a bit squishy. I am sure we’ve all seen estimates that have line items down to the dollar. Like $365,750.00. That’s a terrible thing to do – it implies a precision that just isn’t there.

Don’t EVER leave out contingency! At the project outset, make sure it’s 25% of the total project estimate. And try your best NOT to tell anyone it’s there. That’s YOUR insurance policy to keep you out of the croc pond

Get estimates from multiple sources if possible. Have a technical team do an estimate. Have a trusted project manager do one. And maybe even ask the stakeholders what they think the project should If the numbers you get back are wildly variant, you have a lot of work to do to rationalize them down to something plausible.

BiddersRelentlessly track your actual costs as you incur them! And more importantly, once you see them drifting away from the estimate or any underlying assumptions you made, TELL someone right away. Delivering financial bad news is one thing; delivering financial bad news 75% through a project is PM malpractice.

Figure out who, if anyone, is likely to be joining you in the croc pool. Trust their numbers more than someone who will skate out the side door faster than Usain Bolt if the project costs start going sideways.

rb-

We have all been there, in the croc pond, under the bus, or in front of the train. Someone didn’t complete their task on time or misunderstood a requirement or just screwed up. These suggestions can help insulate you from some of the inevitable problems that are part of being a project manager.

Related articles

 

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedInFacebook, and Twitter. Email the Bach Seat here.

Tips to Blend Agile, Waterfall

Tips to Blend Agile, WaterfallThere is a battle waging for the hearts and minds of project managers. The battle is between Agile advocates and Waterfall supporters according to Eric Morgan, in a recent FierceCIO article. The CEO of AtTask explains that Agile loyalists see the benefit of empowering people and teams in a bottom-up approach that produces a faster, more responsive way of working.  Meanwhile, traditionalists prefer a top-down Waterfall approach that neatly outlines all the steps in the project and defines the scope, budget, and schedule upfront–minimizing risk and uncertainty.

use a mixed approach

So who is right? The article says neither. Rather the article says that organizations with successful development cycles seem to use a mixed approach, using both methodologies for different projects. They cite Amazon (AMZN), an Agile powerhouse, could not have built s core web services product without some top-down dictation of standards. According to the AtTask CEO, the real difficulty for organizations, therefore, lies not in choosing one methodology over the other, but in successfully mixing the two methodologies.

Whether your organization is already juggling multiple methodologies or is considering adding Agile into the project management mix, here are four tips from the AtTask CEO on how to hybridize without sacrificing the visibility and productivity you need:

1. Transition to agile slowly

ScrumThe biggest issue organizations face in adopting or expanding Agile is the cultural transition. Change is never easy, and moving from a top-down culture of command and control to a bottom-up approach where workers self-organize and self-prioritize will certainly test your leadership team. the article stresses it’s a cultural transition that many people in an organization feel is disruptive and too much of a challenge to the established culture. To make the transition smoother and improve adoption, you should try to slow down your process transition. Understand that onboarding a system like Agile is a long-term commitment and because only certain teams will benefit from its methodology, make sure that your organization takes the time to strategically consider where it would be most effective.

Define up front what you are trying to accomplish with Agile so everyone can understand the benefits. In addition, developing a culture of respect and appreciation for both methodologies within the organization is important. Acknowledge what works well with Waterfall and when it is most appropriate to use. This extra effort will build trust; make people more open and resilient to trying new methods; increase buy-in from management and team members; and ensure that everyone is on the same page and trying to accomplish the same goals.

2. Provide professional agile training

With dozens of different aspects and processes, Agile is complex. The AtTask CEO warns that one of the biggest strategic mistakes organizations make is not getting professional training at the start. In particular, it is crucial that middle management participates in training. “Middle management really holds the keys to the success of Agile adoption. They create all the procedures and policies. If the middle is not on board, the transformation will be shunned,” says Dean Leffingwell, author of “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.” When middle management is properly trained, not only do they understand the value of Agile for themselves, but they can be influential in mentoring the team and in demonstrating the value of Agile to the leadership.

3. Allow teams to communicate

In Allow teams to communicatemany organizations, Agile teams often become insulated from the rest of the organization. According to Mr. Morgan, they work in a kind of bubble, rarely interfacing with other teams or departments. However, communication and collaboration are two of the most critical elements of an effective mixed-methodology enterprise. Finding a way to enable visibility and communication across distributed teams, such as developing standard processes for organizing requirements and cross-team development, ensuring comprehensive release visibility for both upstream and downstream stakeholders, and managing the entire work life-cycle within one tool, will make hybrid organizations much more productive.

4. Speak a language everyone understands

The nuanced terminology associated with Agile is often an area ripe for miscommunication according to the author. In addition to making sure everyone understands the terminology and is speaking the same language, it’s important to identify key data points, such as what the team is working on, where the team is along their work process, and when the team will complete the task. Then, translate the data points into either methodology. No matter what methodology your teams choose, the work being done ultimately must be visible to the organization’s management and executive teams. Because manager reports and dashboards tend to focus on Waterfall-centric metrics, Agile teams need to ensure they are able to translate their results and progress accordingly. Moving to a mixed management style will always present challenges.

The article concludes that adoption may happen in baby steps, and not leaps and bounds. Following these four tips, however, can make implementation much more successful and enable you to structure projects in a more productive way to meet your business goals.

rb-

I have talked to several grey-hair PM’s and they have basically told me that Agile/Scrum is the best tool when you don’t know what you want and use PMBOK when you know what you want?

Related articles

 

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedInFacebook, and Twitter. Email the Bach Seat here.