While each organization is unique and struggles in its unique way, there is a common thread: they haven’t prepared adequately for their agile journey. What should you bring on your agile journey? If you’re already traveling, what should you add to your luggage? Here are the top 10 items...
Imagine for a moment that interest in your project catches on like crazy. Hundreds of people pitch in to help you meet an impossible deadline. Complete fantasy, right? It can happen, and it did. And the takeaways for your agile project are real--and powerful.
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!
According to various surveys, many IT projects worldwide use agile methods. What the surveys don’t tell is that many of those projects suffer from the typical ailments of traditionally run projects: compromised quality, technical debt and missed deadlines. Why is that? And what can you do about it?
Are agile practices themselves ever so rigid that they become stifling rather than liberating? Sometimes, strict adherence to an agile framework can cause problems for project teams. Be on the lookout for these issues...
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.
The decision to get agile training is a question that’s part of a bigger one: Whether one is ready to adopt agile practices and principles wholeheartedly. When are you ready? There are four fundamental questions you have to ask yourself before embarking on an agile training program.
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.
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.
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. 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.
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.
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.
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.
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.
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.