It's hard to know if we're producing systems as fast as we could produce them. We can, after the fact, always identify ways in which we "wasted" time without contributing to our desired outcomes. But why can't we identify which will be waste before the fact? Because we want to go as fast as possible!
While self-organized teams are valuable and shared responsibility is the way to manage any project, it seems like a project manager is needed to steer things in the right direction--just make sure you allow them to adapt.
How are you with uncertainty? Do you revel in the possibilities or crave closure? Agile methods have a very different approach to requirements management that some people find empowering...and others find infuriating.
The answer is “yes”, even though the typical fixed-price mentality violates the values stated in the Agile Manifesto. But fixed-price contracts are necessary for the market, so agile projects will have to adjust and offer a workaround.
Forming cross-functional teams is one way out of this dependency trap. But if you just put a group of specialists together, have you really solved the problem? In this article, we explore the downside of over-specialization and write about the sort of people you need to have truly cross-functional teams.
It may not always be apparent, but the goals of the Project Management Office and agile teams are well aligned. Both groups want to get to the same destination, but things often come adrift as soon as the best direction to travel is discussed. It doesn't have to be that way...
In a pure Scrum environment, the project manager's responsibilities are reallocated to the newly introduced roles of Development Team, ScrumMaster and Product Owner. In a hybrid Scrum environment, the project manager role may still exist--but likely in a significantly altered form. PMs need to take the impact of this change on their role and responsibilities into consideration…and plan accordingly.
Why would you not always do as much planning as possible before starting a project? Could it actually be harmful? It all depends on the quality of that input data--when the input data is good, we can reliably plan; when the input data is bad, then we need to get better data and keep evolving the plans.
Choosing the best framework or methodology requires thought, but be careful not to overanalyze it. PMs can gain valuable insight from Bruce Lee’s philosophies, which offer a sound approach to achieve success in any area.
Making a transition from what you’re currently doing to an effective agile process is a project in itself--but it can easily be worth it. There are no guarantees, but let’s look at what we can gain by adjusting our approach...
On an agile project, we often must accomplish the extraordinary. Yet how can we do so when we must work with such…ahem…ordinary people? Here are some suggestions for helping your group of ordinary individuals to accomplish the extraordinary on your agile project.
Making a transition from what you’re currently doing to an effective agile process is a project in itself--but it can easily be worth it. Let’s look at what we can gain by adjusting our approach--our concluding installment looks at interpreting requirements and tracking progress, and offers some further caution and advice.
There is no exact science for people. Just as our project processes should be context-specific, so too should our team processes. Depending on whether your team is brand new, establishing itself or stable, the way we interact as managers and leaders should be tailored to fit the circumstances. Here are some pointers.
Agile methods suggest replacing top-down, command-and-control management with empowered teams and shared leadership. That all sounds nice, but what exactly is shared leadership and how do you get it to happen?
Combining agile and governance seems, at first glance, to imply boxing people in from each perspective and forcing them to chose an option that is neither fully agreeable to each. But this combination is in the best interest of both camps; learn some practical approaches to make it work.
Question: We are totally committed to agile in our production teams, but is there any way to use the agile philosophy for a sales team?
|A.||Agile was written by software developers, and any attempt to move it outside of that sweet spot has proven unsuccessful.|
|B.||The agile philosophy is appropriate for any group that needs a flexible approach to providing increased value to the organization through a collaborative approach.|
|C.||Since the Scrum methodology includes software prototyping, testing and rework, salespeople must learn enough code to experience those parts of the agile process to use it.|
|D.||The agile philosophy is appropriate for any group that needs a step-by-step solution that can be replicated by each team in the organization to provide product consistency.|
New ScrumMasters may understand the “what” and the “how” of their new practices, but they often don’t understand the “why”. Here we look at two common problems: project managers not creating the sprint burndown charts and teams not participating in the daily standup meetings.
It would be simple for a development team to use agile software development practices to improve their development process, likely reducing the injection of defects and possibly increasing their productivity. But what happens if they don’t? A lesson in communication and human behavior may help.
Getting things done is great. And getting these things done quickly is good because we arrive at this better state sooner. So yes, velocity is good…but not at the expense of quality, goodwill or noticing subtle changes in direction. If your obsession on velocity is damaging your team, Appreciative Inquiry can help reset the balance.
As our look at agile development concludes, we will take a more in-depth look at Scrum, XP, Flexible Project Management, the Agile Leadership Model, Agile Project Management, Adaptive Project Framework and Scalable Delivery Model.
What is agile project management, and what are its origins? And don't agile methods address the challenges of 21st century systems, like high-risk, time-sensitive, R&D-oriented, new product and service development projects? One expert takes a look back at the history of this rapidly growing method.
In the future, how will agile methods be remembered by the project management community? It seems history has a way of distorting the facts and simplifying concepts out of context. Given how history has mangled most other project management concepts, the prognosis for agile isn't positive.
What is the true cost of too much multitasking? Is there even a cost? Or is the ability to multitask just plain expected as you advance through the software development career path? Learn what steps to take so that you and your team can become more effective at focusing on getting to "done”.
As a reaction to process-heavy waterfall practices causing excessive delays and major budget overruns, the lightweight practices espoused by agile was a welcome relief. But if agile is such a great solution, why are there failures?
Standardization is the “copy and paste” method of process development. It’s as bad in spreading process through an organization as “copy and paste” is in code. Copying a working instance may be a good starting point, but it’s a bad destination. Creative work needs attentive thinking, even when deciding to not change the status quo.