This site uses cookies to improve your experience. To help us insure we adhere to various privacy regulations, please select your country/region of residence. If you do not select a country, we will assume you are from the United States. Select your Cookie Settings or view our Privacy Policy and Terms of Use.
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Used for the proper function of the website
Used for monitoring website traffic and interactions
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Strictly Necessary: Used for the proper function of the website
Performance/Analytics: Used for monitoring website traffic and interactions
I see many teams and team members who say, “Agile stinks. ” When I ask people what's happening, they say: We're doing an agile death march because someone else already told us what we have to do and the date it's due. And don't get me started on how coaches tend to do life coaching instead of support for agility.)
So when does it make sense to customize your agile approach to gain a strategic advantage? They want an agile approach, so they started with Scrum. The first was not waiting for the end of an iteration to demo or release. They demo'd every week on Wednesday mornings and then they released after the demo. We do what works.”
The teams want to use an agile approach so they can incorporate learning. The managers might even think this is roadmap reflects an agile approach. There's nothing about this roadmap that's agile. You can decide if you need an agile approach. Demo on a regular cadence. The managers want rigid roadmaps.
In Effective Agility Requires Cultural Changes: Part 1 , I said that real agile approaches require cultural change to focus on flow efficiency , where we watch the flow of the work , not the people doing tasks. What about those cultural changes? This is not an agile approach. 1,2 and so on.
Back in Part 1 , I wrote about how stage-gate approaches were as agile as we could use at the time. We had one delivery, so our agility was about canceling the project if we couldn't finish it. Once our customers saw demos, they wanted to change things. Opportunities for Agility. So, more agility than a serial approach.
Opportunities for More Agility. Because we release every time we finish a feature set, we have these opportunities for agility: Re-rank the remaining feature sets. See and demo the product as it grows. If your company can't create an agileculture, consider an incremental lifecycle, especially if you have schedule risks.
Instead, I see assumptions that reveal a divide-and-conquer, and possibly a command-and-control culture, not an agileculture. Divide and Conquer is Anti-Agility I see the product owner and dev team as a divide-and-conquer approach to work. Agility requires a collaborative cross-functional team.
In Effective Agility Requires Cultural Changes: Part 1 , I said that real agile approaches require cultural change to focus on flow efficiency, where we focus on watching the work, not the people. If you and your team have been practicing real agility, you might say these ideas barely show any agility at all.
He thought agile approaches would work to “meet” and “enforce” deadlines. Even when we use a non-agile approach , schedule variance doesn't make sense. Because the “teams” couldn't deliver something small, they didn't demo very often. Over months, they stopped demoing anything.
” For years, I explained that the more often the team or program could demo, the more the project or program could engage its stakeholders. See Customers, Internal Delivery, And Trust for a recent post about demos and trust.) The more frequently you can demo, the more your partners can trust you to deliver something.
I discussed the origins of the agile approaches in Part 5. In this post, I'll discuss how you can create an agile approach that fits your context. Why should you create your own agile approach? Because your context is unique to you, your team, project, product, and culture. Remember, an agile approach starts with a team.
I started asking if you actually need an agile approach in Part 1 and noted the 4 big problems I see. Part 2 was why we need managers in an agile transformation. Part 4 was about how “Agile” is meaningless and “agile” is an adjective that needs to be applied to something. That would be resilient.
Scrum Master or Agile Project Manager? ” (You might like Why an Agile Project Manager is Not a Scrum Master.). She's an agile project manager. When she manages programs, she's an agile program manager. See a ton more about this role in Create Your Successful Agile Project.) Scrum is not her job.
Her ideal readers are the teams doing the work, so they can change their demos and reporting frequency. As a company, we need more demos and more data. However, we all need to see weekly demos according to the attached format. Please ensure your demo is ready every Wednesday by noon Eastern. Was Polly a little snarky?
See Agile Program Measurements to Visualize and Track Progress and Measure Cycle Time for my suggestions of what to measure. I have more ideas and a more in-depth discussion in Create Your Successful Agile Project.). Here are some examples: Demos, even of partially working product. I expect to see some kind of running code.
You have an agile roadmap to see where you're headed. Your team hates having to translate the agile planning into more traditional planning. If you're in this pickle, your manager might think your agile team doesn't replan very often. That manager might assume your team uses an agile approach only as a way to deliver.
After that, they are given access to a simple demo environment with a standard set of configurations, where they can test how our system works. If your company uses other project management tools like Jira, MS Project, or Oracle Primavera, the demo environment will be adjusted accordingly. Organizational culture.
Nor do the teams demo on a regular basis. The teams miss the feedback loops so critical for an agile approach. Their agile transformation falls apart. Let's think about how to create agile projects with short feedback loops, not projects that look like waterfall. Prevent Agile Projects that Look Like Waterfall.
I see too much micromanagement, even in supposedly agile organizations. As an example, when managers don't bother to learn agile measures and what they mean and instead want a Gantt chart, “because how long could it take?” ” Or, when a manager imposes a “standard” agile approach.
Yes, the premise of my Agile and Lean Program Management book.) I have never seen those three conditions in any non-agile project, but that could be my experience and not universal. This team started off with a serial lifecycle, so they didn't even plan to have a demo until about September or so.
In Part 1 , I suggested that when we organize by function, the recognition and rewards might prevent a successful agile transformation. Not only does each team have all the skills and capabilities it needs, but the product line has all the skills and capabilities it needs to manage the culture. Consider a Product-Oriented Organization.
See Agile Program Measurements to Visualize and Track Progress and Measure Cycle Time for my suggestions of what to measure. I have more ideas and a more in-depth discussion in Create Your Successful Agile Project.). Here are some examples: Demos, even of partially working product. I expect to see some kind of running code.
See Why Shared Services “Teams” Don’t Work with Agility. Demo inside the organization. Those pesky FTEs don't need health care or any of the other perks that come with employment. See People are NOT FTEs.) Worse, FTE thinking often leads to shared-services thinking. But they learn as they: Prototype and ask for feedback.
Project lifecycles and cultures manage all those risks. And, you can decide if you want to try to change the culture. Or, you might only need informal demos to show people where you are. Solving Deterministic Problems Does Not Require an Agile Approach. You might show other people internal demos.
and Create Your Successful Agile Project. The closer to the left your products are, the more your managers might be open to changing their behaviors and the culture. TL; DR: “Stop making it harder” is a culture problem. The small-c culture in my team (we would call it a product team now) helped me learn a ton.
Even if a 5 to 7-person team falls into the Everyone Starts Their Own Story trap (see Who’s Playing Agile Schedule Games? or Create Your Successful Agile Project ), the team can still know what's going on. Then, I watched Drunk Agile Episode 75: Team Size. That's when the culture of experience spat in my face.
We organize all of the trending information in your field so you don't have to. Join 55,000+ users and stay up to date on the latest articles your peers are reading.
You know about us, now we want to get to know you!
Let's personalize your content
Let's get even more personalized
We recognize your account from another site in our network, please click 'Send Email' below to continue with verifying your account and setting a password.
Let's personalize your content