Tag: Agile

You may be Agile, but you still need documentation

writing

One of the principles of Agile is “working software over comprehensive documentation”.

I’ve seen many project teams misinterpret this principle. In Agile, working software is valued more than comprehensive documentation. This doesn’t mean documentation is not required. If you start a software project without documentation, you are in for trouble.

Even in Agile, a small set of critical documents are required.

Below are the 4 critical documents needed for software projects:

1) Why (objectives): The Project Charter – All projects need a written document that explains why the project is needed. What problem is going to be solved? What benefits will be had by delivering the project?

This doesn’t need to be a large detailed document. The point is that the team and organization have taken the time to document clear objectives. I’ve seen teams document the MVP (Minimal Viable Product) in the charter. This helps give the team focus on the end goal.

2) What (requirements/user stories) – After creating the charter, the scope of the work needs to be captured. In Agile, the scope is documented in the form of user stories. In Waterfall, the scope is documented as requirements.

3) When (schedule):All projects need to have some form of a schedule. Whoever is paying for the project deserves this. Imagine you are considering paying a builder a large sum of money to build you a new deck. You’re about to sign the contract and the builder tells you he has no idea how long it will take to build the deck. I think the chances of hiring that contractor are slim.

4) How much (budget): The cost of the project has to be estimated, approved, and documented. Through the project, the cost needs to be monitored to ensure you stay on budget.

The act of creating these four documents will force the team to make clear decisions. The documents will also provide direction for the project.

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

To contact us about our services, click here.

The Power of Scrum – Adapting to Change

Scrum

“The Only Thing That Is Constant is Change” – Heraclitus

Unlike Scrum, in a traditional waterfall methodology all planning is done up front. For example, say the objective of your project is to get from Block A to Block B

drawit-diagram

In Waterfall, all steps will be planned out and base lined up front. Once planning is complete, the team will set off on their voyage to get from Block A to Block B.

Using Waterfall, your up front project plan might look something like this:

drawit-diagram-1

Here’s the problem, delivering complex software is a lot like finding your way through the dark. You have to take small steps and feel your way through. You have to adapt and make changes as you find your way.

This is why project teams run into trouble using a Waterfall methodology. They are not ready to adapt to changes when needed, and changes will be needed.

To make things more challenging, using Waterfall customers are only engaged during the start and end of the project. This means all throughout design, build and test the customer is in the dark. This leaves a risk of a system built that is completely different than what the customer actually wanted.

In Scrum, the software teams builds workable chunks of software in short iterations. The team is feeling their way through the dark and adapting to changes as needed. These iterations are called Sprints, and they usually last around 2 weeks. At the end of each sprint, the customer gets to see the built functionality. The below picture represents Scrum iterations:

drawit-diagram-2

By building software in short iterations and keeping the customer engaged, you can adapt to change. The final outcome of the project might look completely different than original expected.

The customer may have realized they actually need to get to Block D, not Block B. Maybe they realized Block D provides much more value than Block B.

See example below:

                                                       Original Plan

drawit-diagram

 

                                          Actual results using Scrum

drawit-diagram-3

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

To contact us about our services, click here.

 

Team building – 3 proven methods to develop trust on Agile teams

hand-reaching-out

All well performing teams have one thing in common, they trust each other. Whether it be a military team, a sports team, or an Agile software development team, trust is key. Team members need to feel that they are in a safe environment so they can do their best. They need to feel that it’s okay to make mistakes.

For software development teams newly transitioning to Agile, developing trust doesn’t come easy. Here are 3 proven methods to help develop trust on your Agile team:

Communicate trust – Let the team know that trust is foundational to success. Empower team members to make decisions and mistakes. Foster a decentralized culture of empowerment. Remember that Agile teams don’t work in a hierarchy structure. There is no project manager calling the shots. It’s the team that has the power. Team collaboration is essential for success and when there’s trust, collaboration will shine.

Now, communicating a team dynamic built on trust is just the start. Just because you’ve let the team know they can trust each other, doesn’t mean they will. The team will be wary of diving into the trust pool. Although they may not be ready to trust, you have planted the seed and the team is interested. Now is the time to walk the walk.

Walk the walk: Show vulnerability and humility – After communicating trust, it’s time to lead by example. We do this by showing vulnerability and humility. This can be difficult for some to do, but it’s absolutely essential. Let the team know when you have made a mistake. Let them know your weaknesses. By showing vulnerability and humility, it lets everyone know they can drop their guards.

If you’re collaborating as a group and a team member is quiet and not engaged, try to pull them in. Let them know their thoughts and ideas are important. Voicing opinions may be new to some team members, so they’ll need a little encouragement. By valuing team members and showing vulnerability, you’ll make great strides towards building trust.

Give it time – The last and perhaps most important need for trust building is time. There is no substitute for time and the positive effect it has on team building. Bruce Tuckman’s 1965 model of forming, storming, norming, and performing still holds true. If you are part of newly formed Agile team, don’t get frustrated when there’s a lack of trust. Just like any relationship, it takes time to get to know and trust each other.

Often, management doesn’t understand the importance of time when it comes to teams. When management shifts people from team to team, it hinders team performance. The best teams consist of people who have worked together for some time. They know and trust each other. Advice to management – Don’t form teams around projects. Instead, form projects around cross functional teams.  

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

To contact us about our services, click here.

50% of your meetings are a waste of time!

boringmeeting

Clutter! It shows up in all areas of our lives. At home, it’s easy to recognize clutter. When I arrive home at night, I can see when clutter starts building up in the kitchen and living room. I blame it on my 3 year old. At work, a different type of clutter happens and it’s harder to recognize.

I’m referring to meetings. We love to fill our calendars with meetings. The problem is that most meetings we attend don’t add value. Yes, when we first scheduled them, they seemed like a good idea. We then discover, after 1 or 2 meetings, they are unnecessary. Yet, we continue to attend them, knowing we are wasting our time.

Think about it. How many meetings do you attend where you provide the same updates, to the same people?

Observe people’s behavior when you are in meetings. Are they engaged and having a dialogue? Or is everyone looking down and frustrated? If the latter is true, there’s a good chance the meeting needs to go.

Time is our most precious resource and we can’t afford wasting it in meetings that don’t add value. Take a good look at your calendar and sit down with your colleagues to review the meetings. Decide what meetings are unnecessary, then get rid of them!

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

To contact us about our services, click here.

 

Page 2 of 2

Powered by WordPress & Theme by Anders Norén