Category: Agile Page 4 of 5

Self-organizing teams produce the best architectures, requirements, and designs

Self-organizing teams produce the best architectures, requirements, and designs.

self-organized team

The above statement is one of the principles behind the Agile Manifesto. Too many “Agile” teams struggle to get this concept.  They have the Agile ceremonies down, and they may even sit together, but they still work in silos based on waterfall principles.

The following statements are all signs that a team is struggling to adopt the Agile self-organizing team behavior:

  • “I can’t work on the design because the requirements aren’t complete yet.”
  • “I can’t create any test scenarios yet because the design is not complete.”
  • “I can’t start development, I have to complete a design document first. “

In Waterfall, the requirements and design process looks like this:

In Agile, it looks more like this:

It’s a cluster of work that happens together. The process gets messy and entangled, in a good way. There are no long drawn out separate phases of development or QA. All the work is happening together, and cross functional team members collaborate through the whole process.

When the team is self organized, that’s when great ideas and valuable products emerge. Why wait for a long period of time for requirements to be completed by a BA, only to be reviewed by the team at a later date? Or wait for a design or dev to be completed, only to be reviewed later?

As Deming used to say, you don’t inspect quality into a product, quality is built-in up front.  Why not use that same principle for how we treat requirements/stories, designs and tests? Instead of inspect quality into them, let’s build the quality in up front by having all team members contribute to the work.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

5 reasons project managers make lousy scrum masters

Lousy Scrum Masters

As the Agile movement continues to grow, the demand for scrum masters has increased. Traditional project managers have caught on and they’re disguising themselves as scrum masters. With a small fudge of the resume, they’re hired as scrum masters. What’s the problem? Project managers make lousy scrum masters.

Now, don’t freak out and get offended. When I first began working as a srum master, coming from an IT project management and QA background, I was lousy. I had a steep learning curve. It’s only after time and working with good Agile coaches that I’ve been able to improve as a scrum master.

The reason we project managers make lousy scrum masters is simple. The two roles are completely different. The original founders of scrum have made it clear that a scrum master is not a project manager. For a description of the scrum master role, check out the Scrum Guide from Scrum Alliance.

Yet, companies continue to hire project managers as scrum masters. Part of the problem is that most business executives don’t understand Agile. I still hear the question from management, “hey can you do that project using Agile”? As if Agile is something you can decide to use like choosing which fuel to pick at the gas station. Agile is a different way of working and thinking. Agile adoption requires commitment and understanding from teams and leadership.

Okay, I’ll get off my soap box. Without further ado, here’s my list of 5 reasons why project managers make lousy scrum masters:

  1. The concept of self-organizing teams doesn’t register with project managers. This may be the most challenging aspect in Scrum for project managers. Project managers are hardwired to tell teams what to do and when to do it. They then expect a full status back in return. In Scrum, the team decides what to work on with guidance from the product owner. The team is then accountable to each other, not to the scrum master. During the daily Scrum, team members should be giving their updates to the team, not to the scrum master. Keeping quiet and letting the team be accountable makes project managers feel like fish out of water.
  1. Project Managers aren’t used to coaching. On traditional projects the project manager is a leader and decision maker. In Scrum, one of the primary roles of the scrum master is to coach the team. They coach in self-organization and cross-functionality. To be able to coach though, one first needs to learn. If the project manager hasn’t learned Scrum, how could they coach the team?
  1. Project Managers struggle to give up being the top dog. On traditional projects, the project manager is the top dog. The buck stops with them. As a project manager, it feels good to have authority and control. In Scrum, you have to let that go. The scrum master does not have authority. The team does not report to the scrum master. The one who has authority on the Scrum team is the product owner. This fact requires project manager to have humility when transitioning to Scrum.
  1. Project managers freak out without a plan. The Project Management Institute teaches project managers to create plans, for everything. If you have your PMP, you know that they expect you to create a giant plan (document) consisting of like 10 sub plans. This plan, the size of the PMBOK, does not change unless there’s some official change request. While Agile still involves planning, this is completely different from Scrum.
  1. Most project managers don’t understand servant leadership. Scrum masters are servant leaders. This means they’re willing to jump in and do whatever it takes to remove impediments and help the team. That might mean helping to dive in and handle low level administrative work. Scrum masters put their ego aside and serve the team. Instead of puffing out their chest and telling everyone what to do, the Scrum Master asks how they can be of service. Most project managers are not used to this style of leadership when they begin in Scrum.

Here’s the good news, it is possible for project managers to become good scrum masters. It takes time and training. It’s like learning to play both guitar and drums well. Yes both instruments create music, but they need different training and skill sets.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

 

 

 

 

Definition of done, what it means and why it’s important

Understanding the definition of done.

definition of done

What is your definition of done? This is a question you often here in Agile software development. In this post I’ll take a closer look at what the question means, and why it’s so important.

Let’s backup, in Scrum the goal is to have potentially shippable product increments at the end of each sprint. “Potentially shippable” means the code is ready to deploy to production if needed. The code should provide some value to the customer or end-user.

The work within the sprint is broken down into user stories. Each story represents a feature or piece of functionality that provides value to the customer.  In order for user stories to be “done”, the following acceptance criteria should be met:

  • Code designed, built and unit tested
  • Code passed some forms of functional, integration, regression and acceptance testing

To speed up the process of “getting to done”, most software groups invest (or should) in automated deployments and automated testing.

But what if we have non development stories, how do we create a definition of done for those?

Some Scrum teams aren’t only delivering software. Here’s my take on defining done/acceptance criteria for non development user stories:

Always aim to have something tangible to show by the end of the sprint. Each story you work on should produce, or contribute to producing, a valuable output. It could be a document, spreadsheet or some other else. Whatever it is, it should be a tangible/completed item that item that provides value.

Remember, much of Agile is based on lean principles. In lean, anything you are working on that does not provide value to the customer is considered waste. The goal in lean systems is to cut waste, reduce constraints, and increase valuable throughput.

So when you are creating your definition of done, ask yourself these questions:

  • If it’s code related, what will it take to be production ready?
  • Whether its code related or not, what will it take to get it demo-ready? Is it tangible and will it provide value?
  • Does the team agree upon what it takes to be done?

What will happen if we don’t create a definition of done for our user stories?

Not having a definition of done for your user stories is a common problem. When this happens, teams usually pull more stories into the sprint than they can handle. They do this because they don’t realize what it takes to actually complete stories. The result is tons of work in progress with nothing getting completed. The more WIP you have, the less valuable output produced.

The increase of WIP is the most devastating effect of not creating a definition of done for your user stories. Nothing will slow down flow more than jamming the pipeline with user stories that don’t have clear acceptance criteria.

Next time you have a Sprint Planning meeting, review your stories to ensure the team knows the definition of done. Even if the team realizes they can only work on 1 story, if at the end of the sprint they have something completed that provides value to the customer, you’re on the right track!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

 

The identity crisis of the IT project manager

The IT project manager role is one of the most in demand and sought after positions in technology. Ask any hiring manager and they will tell you that finding a good IT project manager is difficult. I’ve seen people with the most impressive credentials crash and burn trying to manage IT projects.

So what exactly is an IT project manager, and what makes a good one? The IT project manager used to be the person accountable for managing scope, schedule, and budget for IT projects. Today, that’s still true, for the most part, but the role has a bit of an identity crisis

The Project Management Institute, with their PMP certification, says the role is all about planning and control. If you’ve taken the PMP exam, you know PMI teaches you to create a large project plan. Within that plan are many sub plans for each area of the project.

The PMI has come under scrutiny in recent years by the technology community, and for good reason. With the rapid advancement of technology and globalization, organizations need to be agile. Planning is important, but responding to change may be even more important. Our systems and organizations have become too complex for the PMI plan and control model. This need to adapt to change is what has fueled the Agile software development movement.

With the increase of self-organizing agile teams, it brings us back to the question, what is the role of the IT project manager? Is it an Agile project manager? Is it a project leader? Is it a servant leader? Is it a Scrum Master? Is it a tech lead?

The answer depends, but the role may consist of a combination of all these things. One thing we know for sure is that the IT project manager is a change agent and a leader.

To succeed in this role, one needs to have both hard and soft skills. Good IT project managers use both the left and right hemispheres of their brain. The right side of the brain used for cognitive thinking, the left side for emotional intelligence and relationships. This enables them to be both technical, and emotionally intelligent. Project management is both a science and an art form.

If you are looking to get into IT Project management, you better be able to deal with chaos while keeping your cool. If you currently work as an IT business analyst, tester, or developer, you are well prepped for IT project management. I began my career in QA, and my experience in testing has been invaluable to my role as an IT project manager.

The reason people in these roles make good IT project managers is because they are battle tested. They know what it’s like to be in the trenches of IT projects, and to come out on the other side.

Let’s face it, delivering IT projects is tough. Business executives often don’t realize how tough it is. They are like patrons in a restaurant ordering a four-course meal. As they sit in the dining hall waiting for their meal, agitated by any delay, they don’t see the chaos in the kitchen.

It’s the job of the IT project manager to manage the chaos while portraying calmness and confidence to the team and business. Managing the chaos and leading the project to completion is what makes the IT project manager so valuable.

For me, I enjoy the chaos that comes with delivering IT projects. I particularly like the areas of development and testing. If you love technology, working with others, and solving complex problems, the IT project manager role may be a great fit.

So although the identity of the IT project manager is hard to define, it’s an exciting time for the field. With the rapid advancement in technology and globalization, the demand for good IT project managers will continue to go up.

We have only begun to scratch the surface of the digital world. AI, IoT, and big data technologies are in their infancy. As we chart a course into unknown territories of the digital world, we need good IT project managers to lead the way!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master.

Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

A good Scrum Master is like high performance motor oil

Scrum master

A Scrum Masters role in a scrum team is like that of motor oil to an engine. Cross functional scrum teams consist of lots of complicated moving parts. Software development, testing, infrastructure and release management, are just a few. They all have to work together and if one of these moving parts hits a snag, the whole team can grind to a halt.

This is where the Scrum Master comes in. It’s the Scrum Masters job to remove impediments for the team. Scrum Masters should always be on the lookout for any issues that could affect the performance of the team. It’s their job to clear the way so the team can operate like a high performance engine. This lets team members focus on what they do best and not deal with road blocks outside their control.

Scrum Masters also need to ensure their team’s social and human elements run smooth. This is why you’ll see good Scrum Masters bringing in food, injecting humor, and making the team environment enjoyable. Scrum Masters like to have fun! If you’re not someone who likes to have fun, the Scrum Master role wouldn’t be a good fit. This is part of the reason some traditional command and control style project managers struggle in the Scrum Master role.

Aside from removing impediments and enjoying some fun, Scrum Masters need to be positive. If the Scrum master is positive and optimistic about what they team can deliver, the team will feel the same. The good thing about Scrum is that team members shouldn’t have to worry about long term goals. Instead, they should focus on their current tasks at hand. These are usually tackled in two week sprints. By focusing on the short term assignments, this enables the team to stay positive and feel good about what they can deliver.

The actions I mentioned are a few ways the Scrum Master can act like high performance oil for the Scrum Team. What are some ways you think the Scrum Masters can improve team performance?

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

 

2 huge reasons your Agile team struggles to be Agile

agile teams

In my recent post, problems with Scaled Agile, I discussed SAFe and the Agile mindset.

Aside from debating the value in SAFe, the post created good dialogue about how to foster an Agile mindset within teams. That is, how to help teams become more collaborative, open and trusting.

In my experience, teams often struggle adopting an Agile mindset for two obvious, yet overlooked reasons.

Reason 1 – The team consists of people who don’t like Agile

Think this sounds silly? I can’t tell you how many “Agile” teams I have worked with that had team members who wanted nothing to do with Agile. Not only were they not drinking the Agile Kool-Aid, they were down right opposed to it.

Management makes a big mistake when the put people who aren’t on board with Agile on Agile teams. The thinking is that team members will come around and learn to embrace Agile values. Of course, this doesn’t happen.

John Kotter, Harvard leadership professor, gives great advice on dealing with change resistors. His message is to not try to include them in the change effort. This means, go around them or get rid of them. This may sound harsh, but trying to include anti Agile people in Agile teams causes too much damage.

Managers – When you are forming Agile teams, make sure you bring on people who want to be on an Agile team. The challenge though, is vetting out the Agile imposters.

Reason 2 – People assume roles that do not align with their personality.

The classic example of this is when a traditional project manager takes on the Scrum Master role. A big misconception is that the Scrum Master and Project Manager roles are interchangeable. The truth is the two roles are different. The Scrum master role is about servant leadership. This is different from project management which is more about command and control.

Want to know if a Scrum Master is behaving more like a Project Manager? Attend the team daily scrum and you will find out. If the Scrum Master controls the meeting, they are in project management mode. The daily Scrum is a team meeting, it is not meant for each team member to provide status to the Scrum Master.

Some people who are great Project Managers make lousy Scrum Masters, and vice versa. Make sure you put people into a role that best aligns with their personality and strengths. If you don’t, good luck trying to change someones personality to fit a role.

To recap, if you want an Agile team that embraces Agile values, start by getting the right people on the team. Do not form a team with people who oppose Agile. Next, put people in roles that fit their personality. Do not expect people to change their personality to fit a role.

Like Collins says, get the right people on the bus, and in the right seats!

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

 

 

 

 

The problem with scaled Agile and SAFe

In 2001 a bunch of well to do software developers got together at a Ski lodge to discuss a better way to develop software. The outcome is the Agile Manifesto, a constitution for a new way to build software. What followed was the Agile movement.

At the heart of the Agile movement is the idea that individuals and interactions are more important than processes and tools. Well, traditional program and portfolio wanted in on the action. Fast forward to 2013 and along came SAFe (Scaled Agile Framework). SAFe is a descendent from RUP (Rational Unified Process).

The idea is to take Agile, designed for teams, and scale it at the program and portfolio levels. Organizations are eating up the idea and flocking to SAFe training like sheep.

Here’s the problem, remember that whole interactions and individuals being more important than process and tools thing? Well, in SAFe you are now introducing more processes and hierarchy. This goes against the core principles of Agile. Also, SAFe makes the software development process more complicated.

Developers just want to sit with the customer, write code, and get feedback. Pretty simple right? Below is a picture of the SAFe process from ScaledAgileFramework.com. Could we make things more complicated? It looks like a map they’d give you to navigate DisneyLand.

Scaled Agile

In my experience working on Agile projects, it’s hard enough to get teams to adopt an Agile mindset. It’s not the process or tools, it’s the collaboration, openness and way of thinking they struggle with. This is particularly true if they’re used to waterfall.

Look, for companies that have high performing Agile teams (your Facebooks, Spotifys, etc) I’m sure there is value in SAFe. For most organizations, I suggest they put aside SAFe and instead focus on developing an Agile mindset within teams.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

What happens to UAT in the Agile world?

uat

UAT (user acceptance testing) is often the final activity that takes place in a software development project. Typically, a group of system users will test to ensure all works as expected and there are no missed defects. The users are usually non technical, they are actual users of the product in production. For example, a new code change to a POS system might need a cashier to perform some of the user acceptance testing.

Unlike traditional waterfall projects, Agile methods delivers software in iterative chunks. The Scrum framework develops production ready software in 2-4 week increments (sprints). Each sprint ends with a demo or review with the customer to ensure the product is right. The stakeholders are heavily engaged during the software development process.

This leaves us to beg the question, is UAT required in the Agile world? As someone who spent many years as a software tester before working as a Scrum Master, here’s my take. For most projects I think there is tremendous value in having the product users do some testing. In Agile this may look a little different because you won’t have a UAT phase, but the principle is the same. Let the actual users of the product give a test run before you ship to production.

Could you imagine if Boeing put planes into production before pilots performed test flights? I don’t think you’d ever hear Boeing say, “our QA signed off, but we never had actual pilots do any testing”.  Of course not. The same concept should hold true for most software development projects.

In the Agile world, users can perform their UAT scenarios during the Agile sprints. The users can partner with the dev and QA resources for help and guidance.

Now, here’s the caveat. There are some occasions where UAT may not be required. It’s up to the team and project to make those decisions. For minor enhancements and defect fixes, etc, product demos alone may be enough. For more complex software projects, I think you’d be well advised to not forgo the value of UAT. What do you think?

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

5 Reasons Why Teams Should be 100% Dedicated and Stable

Stable Product Team

If your organization is not using stable product teams, they should be. A lot of organizations are still using an outdated balanced matrix structure. As an example, a company may have different departments or groups for each area of expertise. The project managers belong to one group, the developers belong to another, QA to another, and so on.

Before the fiscal year begins, the balanced matrix business conducts a prioritization process. They define what projects will take place for the year. Once projects are determined, a scramble takes place to form teams around projects. A battle will then ensue between management to staff the best people per project.

This model results in chaos and disorganization. It also results in creating teams that have little chemistry. Even worse, you end up with people assigned to many projects, resulting in switching costs. Some studies suggest that people can lose up to 40% of their productive time by shifting between tasks.

This must stop. Management shouldn’t move people around to different projects because a spreadsheet shows the people have ‘capacity’. It’s 2018, we now know that the highest performing teams are stable teams. The people on the stable teams should be 100% dedicated. What management should be concerned with is the throughput of the team, not resource usage. Efficiency does not always improve by increasing resource utilization. In fact, the opposite will happen if resources are over used.

The biggest reason for stable teams is related to team development. In 1965 Bruce Tuckman outlined four stages of group development, the ‘forming-storming-norming-performing’ model. Aside from having a catchy name, the model still holds true. It means that it takes time for teams to start performing well. This is a big part of the reason why it’s so valuable to have cross functional stable product teams.

Below are 5 huge reasons why your company should have cross functional stable product teams:

  1. With stable product teams, you no longer need to scramble to build teams around projects. All the chaos and competition around forming teams around projects goes away. No need to assign people to projects, instead, let product backlog items flow through stable teams.
  2. With stable product teams, work gets fed right into an already high performing team. This means you don’t have to deal with the forming-storming-norming phases of Tuckman’s model.
  3. Stable product teams improve quality. Quality improves because of the focus and attention the product receives. Team members also grow their domain knowledge and expertise. When team members are 100% dedicated, they won’t have to deal with switching costs.
  4. Work gets done faster and teams get better at predicting velocity. This reduces risk to the release schedules.
  5. Finally, stable product team members tend to enjoy their work. When team members sit together for a while, they get to know each other and they have fun. All the stable teams I’ve been a part of loved to joke around, bring in food, and come up with creative ways to have fun.

The stable product team model works well, perhaps best, using Agile Scrum. If your organization is not using Agile, stable product teams can still work well.

Whatever delivery process you use, let work flow through stable teams. Take advantage of teams that already have momentum, expertise and chemistry. Companies like Best Buy, Target and Pearson have long realized the benefits that stable teams have to offer.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

 

 

 

 

 

Living systems will change when they respond to the external environment

Not being able to gain and sustain momentum is one of the most common problems related to failed change efforts. Maintaining change momentum is critical because the natural movement toward equilibrium has to be countered.

Working on software projects I have seen how important it is to start gaining momentum. In Agile, we use velocity to measure how much work a team can deliver within a set amount of time.

The key here is to start creating flow. Once work starts to flow and momentum picks up, the work output, or velocity, tends to get faster and easier. It is the leader’s job to help the team create momentum, and protect the team from outside forces. If outside forces are changing, the leader must be ready to help the team adapt so the team can sustain momentum.

Darwinian principles state that living systems will change when they respond to the external environment. “To maintain momentum, then, the change leader must constantly monitor the organization’s external environment, being alert to changing forces that require adaptation to ensure survival” (Burke, 2011).

Burke, W. W. (2011). Organization Change: Theory and Practice (3rd ed.). Thousand Oaks, CA: Sage Publications Inc.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Page 4 of 5

Powered by WordPress & Theme by Anders Norén