You’re a hardworking, successful business analyst (BA), and have just been told your organization is “going agile.” Perhaps you’ve heard a few details about the types of roles involved in an agile development environment, but nothing that really depicts how a BA fits into this new atmosphere. So what does this shift in your organization mean for you?
Managing quality during a software development project can be difficult and time consuming when you have been misinformed about true quality indicators and practices. Actively managing quality on an agile project can be both simpler and harder than traditional approaches. Here are some basic practices to save time and unnecessary rework--and improve stakeholder satisfaction before and after delivery.
Project managers need to communicate effectively with all types of project stakeholders. For agile projects, this sometimes involves adapting traditional PM constructs into the closest agile alternatives. Agile pendentives are adaptive patterns that facilitate these traditional-to-agile discussions.
Agile approaches often have greater engagement levels between stakeholders. While those conversations generally focus on the deliverables and how they meet the customer’s needs, can they also drive sustainability best practices?
Agile does not enforce rigid processes, but organizations typically choose a guiding framework and a set of practices that serve as the starting point of an agile transformation. Executives typically want to know where teams are in terms of adopting these new ways of working. This article provides three techniques--individual, team and group--that can be used to assess the agile adoption level, monitor progress and drive improvements.
Have you ever entered a sprint taking on a user story that you later regretted? What can be done to prevent this frustration? Is there a technique that will prevent this from happening, or are these teams doomed to keep repeating their mistakes?
How many of us start a project thinking that we understood the reason behind doing the project in the first place? There’s about half of us who never aligned the project’s mission with the overall department or company vision, resulting in poorly made decisions--and possibly a breakdown in team morale. Providing a project focus that supports a larger purpose is particularly important for fast-paced, adjusting agile projects.
Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer. So why the disagreement? How can smart, experienced people have such different views about the same topic?
Question: After a recent conversion by my team regarding agile, we find that there is a mismatch between the number of hours we should have for working on stories and the amount of time we really have. So we are constantly over-committing to our Product Owner and not delivering. Where are we going wrong?
Traditional teams may have a 15-20% contingency cushion in time and cost on their project estimates. Routinely subtract a similar agile contingency from the number of backlog items you accept to make sure you finish all planned work within a single iteration.
Agile is expected to be flexible, and velocity can vary. Just complete what you can and adjust your velocity for the next sprint if you don’t finish all of the stories you committed to complete this time.
Be sure you are acknowledging hours that team members will spend in Scrum ceremonies, personal time commitments and non-team directed organizational work before calculating the capacity for this iteration.
Ask the ScrumMaster to speak to anyone on the team who did not finish his or her work during the previous iteration. This person is making the team look bad and should be disciplined if it happens again.
A retrospective is a special meeting during which the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change and generate action. This article presents some of the reasons why the retrospective’s efficacy can fade over time and then discusses some interesting techniques to keep them lively.
In agile, we often think of having an experimental mindset where we try something, measure the results, retrospect and replan. We need to do that for our projects. And, as agile leaders, we need to do even more. We need to have the agile mindset.
How do we define quality as a project manager? Is it managing a project really well, or managing a successful project? How about managing a successful project really well? That sounds pretty good. However, it poses the next question: What is a successful project? Let’s look at some examples of project success, failure and ambiguity.
Successful agile development requires that people collaborate in self-organizing their own work. Being told how to do that is counterproductive, yet waiting for them to discover agile practices that work can take a very long time, perhaps forever. What’s a manager to do?
As an experienced agile coach, this writer often gets asked about agile tactics and practices--what works and what doesn’t. There are no singular answers, but there are some generative behaviors and rules for agile done well. In this article, he explores a set of common anti-patterns that he sees in an effort to share what not to do in your agile journey.
Is Scrum better, or Kanban? Which is more suitable for your project? Such questions--and sometimes the responses--put managers in a dilemma about which framework to embrace. Each has its own benefits and tales of success...
The popularity of agile methods among knowledge workers continues to rise. Unfortunately, most organizations that use such methods are actually not agile friendly. In particular, they have grafted the flat, empowered, collaborative agile team construct onto their existing functional power hierarchy. Here are five agile killers to avoid…
How do you know if agile applies to your project? If you are like many project managers, your company is in the midst of an agile transition. Maybe you want to transition to agile, maybe you are already agile…but your organization? Not so much. Here are four tips to see if agile applies to your project.
If we are going to create an environment that is open to change, interactions and collaboration, then we also have to be prepared to deal with difficult emotions and decisions. And managing people in an agile environment requires social acumen...
Agile testing is commonly mistaken as only referring to the Quality Assurance/testers on the team. This is a destructive, limited view of this critical agile development piece. This article places the emphasis on the often neglected, misunderstood and essential collaboration tool.
In attempting to make agile methods scalable, it is tempting to add more process to assist larger-scale coordination. However, that is the last thing we should do. Scaling collaboration, not process, is the key to enterprise agility.
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
This is the final article in a three-part series on the factors to consider when determining whether an organization, team or project is “ready” for agile. This third installment continues the discussion by examining factors that are specific to the project itself and whether it is really suited to an agile approach.
Can agile teams--even high-performing ones--burn out? Of course. Far too many teams seem to schedule their sprints sequentially or back to back, without a pause or break. So if you are suffering from burnout, what are some helpful techniques to refresh and recharge your teams?
by Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
This second article continues the discussion by looking at the second group of factors related to the readiness (and willingness) of the project team to adopt agile best practices. As with sponsorship factors, we need to consider cultural, structural and management aspects.