Agile project management, and particularly Scrum, can become overwhelmingly consumed by methodology, jargon and rules. This is just the opposite of what was originally intended for agile-lead projects, and it is the communications part of our role that is so important.
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.
Question: Today a person appeared at my desk saying he was the new Business Analyst for the team and he set up a meeting with me for next Tuesday. I didn’t want to appear stupid, so I just said okay. We’re an agile team, so is he replacing me as ScrumMaster, or what? Should I be worried about my job?
The Business Analyst (BA) certification is the replacement credential for the old Project Management Professional (PMP), but with an agile flavor. Check online to see how quickly you might get this new certification if you hope to continue on with your organization.
Rather than replacing a project manager or ScrumMaster, the BA is the representative of the Customer or Product Owner who is funding or authorizing your project. He will benefit the team, as he may have more availability than the actual Product Owner.
The BA is a junior version of a Quality Assurance team member, and can help you finish your projects more quickly since he does not have the test backlog of a seasoned QA person.
The ScrumMaster reports to the Functional Manager whose department will benefit most by the completed project deliverable. Perhaps the BA made an error in contacting you.
We've covered certain challenges a project manager is likely to face when a Scrum transition is first being evaluated, and a comparison between Waterfall and Scrum methodologies. Part 2 of this article covers the ScrumMaster and Product Owner roles in the Scrum environment--and also addresses the project manager’s role during and after an organization's transition to Scrum.
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.
Question: I’ve just been chosen as ScrumMaster for my agile team. I know I “remove obstacles”, but I’m concerned about what I can do on a daily basis and what is overstepping my role and moving back to traditional project management. How can I make this a better team?
The ScrumMaster role is non-technical, which is a reward for outstanding technical performance in the past. In essence, you retire at full salary.
The ScrumMaster has a key role in improving team performance, so find your own way to structure the team processes and to facilitate team development.
Since the team is self-directed, wait until team members present obstacles at daily scrum meetings and then tell a manager to remove them.
Find an experienced ScrumMaster in the organization and ask if you can shadow them for two days a week. Then, follow their directions so that all the agile teams are working alike.
Life gets really interesting when we start to extrapolate the brand identity concept into our project methodologies. What drives the decisions about what different organizations use? And is there any tangible benefit to choosing a “brand label” project execution approach?
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”.
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
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.
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.
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.
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…
You've probably read many articles on the difference between traditional project management and agile (specifically, Scrum). One practitioner has been surprised with how established agile practitioners don’t want to let project managers into their “club”. Why can’t project managers become agile?
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.
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...
Anytime you get a large number of people working on something, there are going to be differences in style and capability shown in that work. When that work is software development, then some of those differences are arguably better or worse for the maintainability of the software. So how do you achieve a better and more consistent outcome?
We've already looked at the opportunities agile methods offer for proactive risk management and examined the benefits of engaging the whole team in risk management through collaborative games. As our agile risk management series continues, we walk through those games and explains how to engage a team in the first three of the six risk management steps.
If you’ve ever been involved in a highly visible project in which major stakeholders are jockeying to position themselves to impose their own agenda, then you would have experienced project partisan politics. And If you are a ScrumMaster on an agile project, there isn't a more important impediment to get out of the way.
Code inspections are an implicit, often unspoken best practice among agile project management teams. This silence has caused some people to question the quality control of the agile PM paradigm. Surprisingly, agile teams have not forgotten to mind the Ps and Qs of quality engineering--and not only continue to perform code inspections, but perform them more often. This results in even greater quality than traditional project management teams.
How do these two roles stack up against one another? Can a project manager adapt to being a ScrumMaster? Given the opportunity and environment, people can be successful in a number of different roles--provided that there is some degree of connection.
While it is their own personal goal to maximize team productivity and minimize any stumbling blocks along the way, it is also sometimes necessary for a ScrumMaster to act as a guardian and help protect their team members. Just don't get too aggressive on the field...
How do we adapt in the face of consistency, or of anarchy or of brutal regimentation? As project managers, the only thing we really have control over is ourselves. Given this, how do we change our approach in a way that enables us to be effective in producing project results, rather than bashing our head repeatedly against an unfeeling and unchanging wall of bureaucracy? Here we take a look at adaptation in the face of organizational consistency.