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.
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...
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. |
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 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.
Question: My organization outsources to save money, but it creates communication issues and other problems for my agile team. Can offshoring (outsourcing) work effectively for non-collocated agile groups?
| A. | Yes, but success may depend on how far away from your collocated team the outsourced resources are located. |
| B. | No. Agile practices stress collocated teams. If you are not based together, there is no way for an agile approach to be effective. |
| C. | Yes, but only if the teams switch the locations where they live every six months so that each group learns the language and culture of the other. |
| D. | No. Agile was created in the United States, and therefore it is only intended to work for American teams. |
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.
Question: My organization has one successful agile team, but we need to expand to more teams. How can we add more teams, but keep the way we do things consistent?
| A. | Divide your successful team and place one person in each of the new teams you want to adopt agile. |
| B. | One agile team is enough for any organization. Leave your other teams using their previous techniques. |
| C. | Slow down and bring one or two new people into your existing team to learn, then split the teams. |
| D. | Run an agile camp on the weekends for six weeks and have the successful team train the new people. |
Aren’t resolutions just mini-projects you want to accomplish? What better way to do that than by leveraging agile! The Scrum framework is best suited for this. Let’s look at how to hack Scrum for personal productivity…
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.
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?
While our activities involve human interactions, creativity and collaboration, many managers act as if their organizations should function like a well-oiled machine. Mechanistic thinking is so embedded into the work of project managers and knowledge workers that we often fail to notice it, and that needs to change.
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.
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.
No manager wants to demotivate their team, but sometimes their actions have unintended consequences. How can well-intentioned actions backfire?
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.
Everyone wants improvement. But do you know how to get it? Most people want to do a good job and improve. To do so requires three factors: information, time to reflect and learn, and a desire to improve.
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.
Whether you call them DANCE, VUCA, agile or just plain challenging, the need for outdated PMOs to catch up is clear. PMOs are changing--and it looks like they are becoming more agile. This article examines the pressures for PMO change and where they could be heading.
Being clear about what constitutes “done” ensures that the product or service developed at the end of an iteration is completed to the satisfaction of the customer, which is the whole purpose of doing agile in the first place. Got it? Just in case, read on...
There is a growing school of thought in the practice of leadership that we do not follow people. Instead, we commit to following stories that resonate with us. The story is the leader, not a person. What is your story? What story will others tell about your agile project? The questions are important because of the power of story.
|