Question: My team prefers to work in Story Points, but it sometimes becomes hard to deal with the realities of how to estimate a first iteration and how to deal with the availability of the team members. How do experienced agile teams handle these realities?
A.
If you want to be agile, you must estimate in Story Points. Nothing else will really work for a team once they begin to do the work of the project.
B.
Neither is the correct approach. Estimate your Product Backlog in Ideal Hours, and then they will transfer over easily to the iteration work of the team.
C.
If you create software, use Story Points. If you use agile for any other type of project, estimate in work hours, which you can input into MS Project.
D.
Use Story Points for the Product Backlog, but actual hours for the Iteration Backlog.
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...
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.
Question: The software developers in my IT department are hardcore agileists. I maintain legacy systems and do operational work. Is there anything I need to know about the agile world that could affect my work with hardware?
A.
Yes. Cloud computing is an agile practice and a major trend that will probably be discussed in your workplace soon. Learn about it so you don’t look dated and out of touch.
B.
No. Agile is only for software developers at large shops like Google who need to support online retail sales and search engine banks.
C.
Yes. All hardware purchase and installation projects should be converted to a Scrum process for the greatest impact and cohesion between teams.
D.
No. The government has legislation pending to block agile practices as potential antitrust violations.
One team or a handful of teams may be able to deliver small systems with agile, but large complex systems require teams of teams to deliver significant features. How can companies benefit from “the team effect” at scale?
Have you noticed any hints that your company isn’t customer intimate? Companies and their supportive corporate culture sometimes say one thing and yet practice another. Learn how to inspire your team to be customer intimate--in part by utilizing agile, which takes this approach to heart and emphasizes customer-centric product development.
Imagine you are transitioning to agile. You are a program manager with a few agile projects and a traditional project. How do you manage the program? Here's some help in bridging the gap between two schools of thought.
Agile methods recommend dedicated, co-located teams...so how do they fair when used in part-time, distributed environments? A lot of challenges await, but with the right outlook you can conquer them all.
We've already traced the genealogy of Kanban. It’s now time to start looking at the evolution of Kanban from its manufacturing roots in the automobile industry to its current widespread use in software development. This will ultimately allow us to see where practices and tools like Lean and Kanban go to the “beyond”.
Question: My project “teams” are random, siloed people housed all over the building. We never meet, and multiple project managers all use the same departmentalized individuals to complete activities. How do I get them to prioritize my work requests?
A.
Ask your organization to restructure from a traditional hierarchy to a projectized organization.
B.
Offer free coffee mugs, t-shirts and award certificates each time someone completes an activity for your project.
C.
Show your manager that having these people moved to a common workspace for the duration of your project will add value to the project deliverables.
D.
Transition yourself from a project manager to a project leader and create a sense of connection and personal relationships between these random, siloed workers.
We all know that process improvement is important, but who should deliver it? Whoever owns a process should also be accountable for the improvement of it--and when we are talking about PM processes, that frequently means the PMO.
It doesn't matter whether you work for a big or small company: When delivering a product that requires the work of more than two teams, dependencies are part of the picture. Time after time, projects are tangled up in dependencies. Does it have to be this hard? Some dependencies are inevitable, but some are self-inflicted...
Kanban has been synonymous with Lean since its origins were from that movement, but we have also witnessed a spawn of new iterations. These are all testaments to its growing popularity and influence. This article will be the first in a multi-part series that will cover Kanban in terms of its origins and genealogy, current use in the software development and project management industry and the possible future trends of this very interesting workflow visualization tool.
One of the best ways to make sure your agile program is successful is to think about how to make everything "smaller" to better manage potential risk. Here are six tips for making your large efforts “smaller” to achieve maximum benefit from your agile programs and to help them maintain progress.
Two natural traits separate those that conquer agile environments from those who muddle along to mediocrity. Think of these traits as your “IT” department: Ingenuity and Tenacity. In them, there is an abundance of hope for all of us immersed in the world of agile project management.
Teams work best when they are empowered to self-direct and given freedom to self-organize. Yet striking the balance between providing this autonomy with responsible project oversight can be tricky. We want to create empowered teams, but we also need to know if the project is going awry and when to intervene. A great source for creating empowered team environments can be found in the prescriptive process of PRINCE2.
How can PMOs--which are renowned for their classic command-and-control structures and often maligned for their lack of flexibility and strangling bureaucracy--even begin to share headspace with terms such as “lean” and “agile”?
In this third and final installment, we will look at how agile can be re-contextualized for the business environment at large to transform not only specific projects or processes in an industry, but also entire organizations within that industry to meet the growing demand for faster project turnaround while also achieving higher quality and business value.
What tools do agile project managers use most often? If Gantt charts and network diagrams are no longer the tools of the trade for agile project managers, what are? How do today’s projects communicate status, report progress and illustrate what is coming next?
Do you use Iteration Zero for your agile projects? An Iteration Zero is an iteration where you set up all the servers, make sure you have a release plan, develop a product backlog and in general do all those things that “assure” you that your project is ready to go. While not a fan, this writer admits there are times when Iteration Zero can help your project or program.
At the recent Agile 2012 conference, our trusty expert reveled in the overview presentations, how-to sessions and hands-on workshops showcasing lean, Kanban and agile techniques. But it was the presentations on the use of agile outside of IT and a couple of high profile “questioning agile” sessions that truly caught his attention.
Part 1 of this series discussed the background environment and philosophical divergences that caused agile to establish itself as an alternative to traditional project management. With that background established, it’s now time to start thinking about the where agile is headed and how it will get re-contextualized for the 21st century.
As a practitioner, thinker and writer of agile project management, one writer often like to assess where we’re at with agile as well as where we’re headed. As a practitioner, he likes to know how to apply an agile practice or method and keep up to date with what’s coming up in the industry. As a thinker and writer, he likes to understand where agile fits in the overall “big picture”--as well as foresee and anticipate future trends. This will be the first of a multi-part series that will attempt to assess agile from such a perspective, and to foresee how agile can be re-contextualized for the 21st century.
For those project managers practicing agile practices and methods, you already have all the ingredients in place to optimize your green initiatives. This article will attempt to illustrate how agile principles can enhance and compliment projects that have sustainability as one of its main end goals.
The frequency and magnitude of IT project failures are so prevalent and epic that people can appear in denial of their ability to influence, or “in acceptance” that a certain percentage of projects just go south. Does it need to be that way? If we spent more time asking people where stuff could go wrong rather than making ever more polished models of flawed project plans, could we change the statistics?
An agile architecture and design should be right-sized to fit the scope of the release plan and no more. This is true whether the architecture is created in a traditional top-down or agile bottom-up style. This means that an agile architecture and design can be visualized within the initial release planning phase when a lightweight plan is created--and the most business value to a customer is achievable. Here are some of the practices for agile architecture and design.
Any project team that doesn’t manage its current and legacy technical debt will eventually discover that it is impossible to produce features. It’s a slippery slope. Here’s what an agile project manager can do to work with a project team and a product owner.
|
1.gif)
