Tag: Agile Page 1 of 2

Everyone On The Delivery Team Is Responsible For Quality


When it comes to software quality assurance, most people think of phase at the end of a project. This testing phase is usually performed by “quality assurance” testers. The traditional project delivery model is to blame for this. As someone who worked as a software tester for years, I know about the pains of doing all testing at the end.

The problem of course is that when testing happens at the end, after a development phase, it is too late. What you are doing is trying to inspect quality in, instead of building quality in.

Lean manufacturing and lean software development is about building quality in. This was one of W. Edwards Deming’s, a pioneer in the lean and quality movement, motto’s . To build quality in, testing should take place all throughout the project. Testing early reduces the cost of defects because the earlier you catch defects, the cheaper they are to fix.

For this reason, it is well advised for software delivery teams to apply lean principles and automate as much as possible. Automation shouldn’t only be a set of regression tests that run at the end. Automation should take place all throughout the entire software development and release process.

Automation can begin in development using test driven development (TDD). For more on TDD, see my post on why automated testing is needed early and often.

After TDD, automation can be applied from build and deploy to acceptance tests.

This brings us to the process of Continuous Delivery. Continuous delivery is all about creating reliable software releases through build, test, and deployment automation. Today, more software organizations are reaping the benefits of continuous delivery, yet for most it’s still a pipe dream.

People think the idea of automating everything is too daunting, or can’t be done for their application. More and more we are now seeing that continuous delivery can be done, for any application or organization, no matter the size. A good way to start is by looking at your current release process, and finding the biggest bottlenecks. You can then start to automate over time, targeting the bottlenecks first.

By automating the whole software release process, you build quality in. This makes everybody on the delivery team responsible for quality, not just a “QA” team who tests at the end. For manual software testers, continuous delivery enables them to focus on exploratory testing.

There are many other benefits to TDD and continuous delivery, but perhaps the greatest is the reduction of stress for delivery teams. If you’ve gone through a production deployment process, using manual processes and ad-hoc configuration techniques, you know what I’m talking about.

For those who already use lean development techniques this information shouldn’t be news to you. If you still work in an environment that uses SDLC processes with little to no automation, the topics I’ve covered only scratch the surface.

Some great books I recommend on lean software development and continuous delivery:

By using continuous delivery and automating as much as possible, everyone on the delivery team is responsible for quality.

About the Author: Mike MacIsaac is the president 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.

 

Why I Love Agile (And You Should, Too!)

After recently starting a new consulting engagement as an IT program manager, I’m reminded why I love Agile.

I love Agile

 

For most companies, sticking with a Waterfall software delivery model is like being in a bad relationship. No matter how much you know and feel something is wrong, you keep going back to it.

It could be due to the comfort of the familiar. Sometimes the idea of changing to something unfamiliar is too frightening, even when we know we should.

One of the major problems I see with Waterfall is that it sets the stage for people to work against each other. Each phase in Waterfall provides the perfect recipe for friction among people who are afraid. What are they afraid of? They’re afraid of being blamed if things go wrong.

What if the project fails and they blame it on my requirements? What if they blame it on my software design? What if they blame it on my development or testing? The result of this fear is people working against each other.

In Agile you break down the barriers of fear and distrust by bringing people together into cross functional teams. When we bring the different phases and groups together into one unified process, we can achieve great things.

Agile is about people collaborating and connecting with empathy, while creating synergy to achieve a common goal. In my humble opinion, the greatest benefit of Agile is that it brings people together. That is why I love Agile.

About the Author: Mike MacIsaac is the president 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.

Kanban vs Scrum – What You Need To Know

Kanban vs Scrum

If you are familiar with Agile you know about Scrum and Kanban. While these two Agile frameworks have similarities, they are also very different. Their differences go way beyond stickies on boards. In this post I’ll describe the two frameworks and their history, as well as their benefits and differences.

Scrum OverviewScrum is by far the most used Agile framework. Credit for the framework goes to Jeff Sutherland and Ken Schwaber. Scrum got under way back in 2001 after the creation of the Agile manifesto.

Scrum is great for complex software delivery projects. In Scrum, there are defined team roles which are Product Owner, Scrum Master, and development team. The Product Owner creates a backlog of user stories that define the scope of a project. The team then completes the stories in short iterations called “sprints”. Sprints usually last 2-4 weeks. Sutherland was influenced by his days as an Air Force pilot. He relates the team sprints process to coming back from short missions and landing the plane on time.

The goal is to have working software, approved by the Product Owner, at the end of each sprint. The stories worked on in the Sprint should be done (all testing completed..etc). The key metric used in Scrum is Velocity. Velocity is the average amount of points a team can complete in a Sprint. Within Sprints, change to work is discouraged.

The stories completed in each sprint represent part of the total project scope. The team repeats this cycle of sprints until all stories in the backlog are done, in which case the project ends.

Kanban Overview  – “Kanban” get’s its origins from the Toyota Production System. Back in the 1950s, Taiichi Ohno created a pull system for Toyota. The idea was first sparked by his experience in American supermarkets. He was fascinated by how shoppers would walk down the ails pulling only what they needed from the shelves and putting it into their shopping carts. Shoppers usually had a list they carried which told them what they needed.

In Toyota plants, “Kanban” are instructions in clear plastic that communicate information needed at work stations. In a sense, a Kanban is like a grocery list. When an order comes in, a Kanban would be used to pull the whole car creation process together. Each item needed for the Kanban is ready just in time (JIT). This enables minimal build up of inventory. In a lean system, the goal is to reduce waste. The build up of inventory is the worst form of waste according to Taiichi Ohno.

The principles of the Toyota Production system were emulated in lean software development when Kent Beck created XP (Extreme Programming). The goal was to use the JIT principles and limit work in progress to the teams capacity. Beck also implemented a test driven development (TDD) process that improved quality. XP can be considered a different Agile framework from Scrum and Kanban. In my view, XP has more of relation to Kanban, since Beck based most of the practice off of Ohno’s Kanban method.

Unlike Scrum, Kanban is usually not the framework of choice for software delivery projects. Projects have a clear beginning and end, as well as a defined scope. Kanban works well for support teams, where work will be ongoing.

Teams will use a Kanban board, like the board a Scrum team would use for their Sprint. There are no Sprints in Kanban, the work is a continuous flow. There are also no defined roles in Kanban, like there is in Scrum. Cycle time is the key metric used and unlike the Sprints in Scrum, in Kanban change can happen at anytime.

Some of the benefits of Kanban include flexibility in planning, increased throughput, fewer bottlenecks and visual metrics. Kanban also compliments continuous delivery.

Below is a grid that Dan Radigan from Atlasssian put together, which displays the differences between Kanban and Scrum.

                                          Scrum                                                             Kanban

Cadence Regular fixed length sprints (ie, 2 weeks) Continuous flow
Release methodology At the end of each sprint if approved by the product owner Continuous delivery or at the team’s discretion
Roles Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach.
Key metrics Velocity Cycle time
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time

Summary

Scrum and Kanban are two different Agile frameworks, but both have many benefits. In my view, Kanban is more aligned with lean development than Scrum. The area where Scrum gets into trouble with lean is the idea of having a team create and work on a large backlog. Lean experts, like Mary Poppendieck, cringe when they hear the word backlog. This is because it goes against the principles of JIT and low inventory. At Toyota, I’m sure the plant manager would freak if they had a large backlog of orders piling up. They want to have low inventory and good throughput. While Kanban works great for a repeatable process, my view is that Scrum is the best framework for complex software delivery projects.

If you enjoyed this post, check out The Top 10 Influencers of Agile.

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 art of being an Agile project manager

Agile Project Manager

The Agile project manager role has become quite common. As more organizations adopt Agile, the traditional project manager role has morphed into a hybrid Scrum Master. For those of us working as Agile project managers, we have the challenge of blending two different, even opposing, roles into one. It begs us to question, can one even be an Agile project manager? Ken Schwaber seems to think so. The co-founder of Scrum wrote a book called “Agile project management with Scrum”.

Let’s back up and take a look at the differences between a Scrum Master and a project manager.

  • The Project Manager – If you have your PMP, you know that project management is all about planning, control, and communication. The traditional project manager role is big on command and control. The PM has authority over the team. The PM manages the team, assigns work, and is accountable for the success of the project. The PM is responsible to create a detailed Gantt chart project schedule and all planning happens at the start of the project.
  • The Scrum Master – If you have your CSM, you know that a Scrum Master is not a project manager. Whereas the project manager is about command and control, the Scrum Master is about servant leadership. The Scrum Master does not have authority over the team, he is more of a guide and coach. The Scrum Master shields the team from interference’s. He removes impediments, and ensures Scrum the team understands processes and values.

Knowing the differences between the two roles, we can now see how working as an “Agile Project Manager” is an art form.

Below are some tips to help you be an effective Agile project manager:

  1. Let go of the idea that Agile or traditional project management has to be one way, all or nothing. Organizations are complex and tackling a change like Agile adoption is difficult. This is especially true for large organizations used to rigid structure and control.
  2. Don’t be afraid to switch hats, between PM and Scrum Master, when necessary. For example, I try to empower the team and not tell people what to do (with my Scrum Master hat on). Yet, when the team starts running into trouble, I create a sense of urgency and give direction (putting my PM hat on).
  3. Help to educate the leadership team on the difference’s between Agile and Waterfall. The real value in Agile is in the core values, not the practices. In fact, most Agile projects that fail are a result of company culture not aligning with Agile core values.
  4. Make the Agile ceremonies mandatory. Agile teams may be self empowered, but you have to at least follow the key ceremonies. If you’re not having daily standups, sprint reviews and retrospectives, don’t call yourself Agile. These Agile practices are low hanging fruit. They are the easiest things for teams to adopt. The hard stuff is getting the core principles right.
  5. Perform the Agile PM role to the best of your ability, and do it with a smile. Whether you are an employee or a consultant, your job is to fulfill the need of the organization. Try to improve processes, but as Dale Carnegie says “don’t criticize, condemn, or complain”.

The art of being an Agile project manager means being flexible and willing to lead. It means accepting that some roles won’t always be by the book.  It means understanding the value in both the Scrum Master and PM roles, and finding a way to make them work together.

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

To contact us about our services, click here.

 

 

 

 

 

 

Root cause analysis – Why toddlers are better at it than us

root cause analysis

If you’ve ever talked to a toddler, you’ve been hit with an endless amounts of whys…

Dad, why do you go to work? So I can make money. Why do you need to make money? So we can eat. Why do we need to eat? And on and on it goes.

Well, it turns out we need to learn from toddlers. Their relentless, and annoying, asking of why is what we should be doing for root cause analysis.  Working in technology, we deal with problems all the time. When we’re confronted with problems, the majority of us don’t take the time to do a good root cause analysis. This results in problems coming back to haunt us.

For example, say an application stops working. The team begins to triage the issue, and discovers a service stopped running. The service gets restarted, application relaunched and all is well. Or so the team thought. The next day the application stops working again. After inspection, the team finds again the agent needed to be restarted.

The agent stopping was only a symptom, and not the root cause. This is why we need to use “the 5 whys” when confronted with a problem. By asking why 5 times, you’ll dig deep enough to get to the core of the problem.

Repeating why five times is a process that was first used by Taiichi Ohno in the Toyota Production System. It is now a common practice in Lean software development.

In the example I gave above, the 5 why scenario might look like this:

  1. Why did the application stop working? Because the service stopped.
  2. Whey did the service stop? Joe performed an install and forgot to restart all the agents.
  3. Why did Joe forget to restart all the agents? Because there is no documented process about restarting agents.
  4. Why is there no documented process? Nobody took the time to do it.
  5. Why didn’t anyone take the time to do it. Everyone is busy fighting fires, nobody has the time.

In the above scenario, by asking why 5 times you get to the root of the problem.

Creator of XP Kent Beck writes: “After Five Whys, you find the people problem lying at the heart of the defect (and it’s almost always a people problem).

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

To contact us about our services, click here.

References: Beck, K (With Gamma, E.). (2005) Extreme Programming Explained, Upper Saddle River, NJ, Pearson Education, Inc

 

 

 

 

Leading cause of failed Agile projects? Company culture not aligned with core Agile values

In the 2015 VersionOne state of Agile survey, the top reason for failed Agile projects (46% of respondents) was company culture being at odds with core Agile values.

fail_at_strategy

I’ve experienced this myself. Companies understand they need to get better at delivering software, so they decide to assemble Agile teams and bring in training.

The Agile teams use all the Agile practices, yet leadership sees little improvement. Why is there little improvement? Usually it’s because the company has a philosophy and culture that are at odds with core Agile values.

Below are the core values outlined in the Agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Organizations have to have the ability to adapt to change. The advance of technology and globalization have made this an absolute need to stay competitive.

Adopting Agile is not just about improving how a small project team delivers software. It’s bigger than that. Leadership has to get on board with Agile values and principles. Organizations of the future will be dynamic,  fluid, and need leadership at all levels. The days of a static hierarchy org structure will soon be long gone.

The question remains, what should leadership do to align the company culture with Agile core values? My advice is to not try and change the culture head on. Many have tried and failed. Instead, allow the Agile team(s) to adapt their own rules and culture. Think of them as an organization within an organization. Allow them exceptions to old buerecratic processes. Help them remove any impediments that’s slowing them down. Let them develop their own mini culture.

Once you do this and start seeing success, you can then begin to expand out the new culture. The idea is to start changing the company culture in small chunks, one area at a time.

For large organizations, changing company culture is a monumental challenge. You need leadership at the top to champion the change. You’ll need buy in and a sense of urgency.

Once Agile core values align with company culture, product delivery will go faster and changing priorities will be managed better.

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

To contact us about our services, click here.

 

 

 

 

The powerful benefits of value stream mapping – improving your software development process

projmgt

Value stream mapping is a powerful tool. It’s used to identify and remove bottlenecks in your organizations value stream.  Before going further about the mapping, let me first touch on what a value stream is. I’ll also describe the theory of constraints.

Your organizations value stream is the end to end process used to deliver a product to the customer. For example, it may begin as a request from a customer, and end once the customer has the finished product. The stream contains all the activities it takes to get the customer the finished product. Each activity contains a work time, and a wait time.

The theory of constraints says that the best way to optimize an organization is to focus on throughput. Throughput is the key to generating profitable revenue. The way to increase throughput is to look for the current bottleneck that is slowing things down and fix it. Once removed, find the next bottleneck and fix that. Keep this up and you will have a fast-moving value stream (Goldratt, E 1984).

Creating a value stream map – “Mapping your value stream is a good way to start discovering waste in your software development process. In industry after industry, the process of mapping the value stream has invariably led to deeper insights about how internal processes work or don’t work to meet customer needs” (Poppendieck, 2003).

An easy way to create a value stream map is to have a project team gather around the whiteboard. The process shouldn’t take long. You should be able to do this in an hour or less. Write out all key activities in your value stream. For each activity, write down how much work time it takes, and how much wait time there is.

For example, you may find it takes on average 2 weeks to code for a project, but it takes an extra 3 weeks to move the code to test. This extra 3 weeks is wait time that doesn’t provide any value to the customer. It is waste.

After creating the value stream, identify the biggest bottlenecks in your process. The goal is to increase flow and value added time in the system. Focus on the fixing the biggest bottleneck, then continue to fix the next bottleneck.

In software development, it is common to find that the biggest bottlenecks occur after development and testing are complete. This is why it’s so important for organizations to be moving towards a lean software development model.

Below is a picture of a value stream map from the book Lean Thinking, by James Womack and Daniel Jones.

 

lean-and-kanbanbased-software-development-14-638

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

To contact us about our services, click here.

References:

Mary and Tom Poppendieck, Lean Software Devleopment

Eliyahu M. Goldratt, The Goal

Lean software development, trust and empowerment

once-cycling-team

Trust and empowerment are the fuel that drives high performing technology teams. Companies like Facebook, Amazon and Spotify have realized this. They all use lean software development principles. They are cutting edge Agile. They have achieved a continuous delivery framework. They deliver quality software to production almost every 11 seconds.

So what does lean software delivery have to do with trust and empowerment? You can’t adopt a lean software development framework without empowering and trusting the teams. Using lean, management tells the team the problem, but lets the team decide how to solve it. Using lean, management let’s teams deploy software to production. This means there is no wait for a release date or a release management team to deploy software.

Can you imagine, as soon as software has passed testing, it’s deployed to production? It sounds like a fantasy, but it is not. Companies like Spotify have been doing this for years. If you want to stay competitive, you need to be moving towards a lean continuous delivery model too.  

Most companies are the opposite of lean. They have long release cycles, maybe delivering new software to the customer on a monthly or quarterly basis. They follow a strict release management schedule, riddled with controls. The whole process is filled with waste that slows down the delivery of working software.

An underlying principle of lean software development is to cut waste. Waste is considered anything that doesn’t add value to the customer. If you take a good look at the software development system within your organization, odds are you will find a lot of waste. Waste only delays the delivery of working software to the customer.  

This is why management needs to let go of control. They need to empower and trust their teams. The real strength of high performing software companies comes from the teams.  Marry Poppendick, author and expert on lean software development, writes: “Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work” (Poppendieck, 2003).

Trust and empowerment are the foundation of great teams.  They are the fuel that propels the team’s forward. Trust and empowerment enable lean software development in an Agile framework. The result of lean software development is satisfied customers. Satisfied customers are the most important aspect of the software development process. When you have satisfied customers, you have achieved quality.

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

To contact us about our services, click here.

Quality and the consumer – The 3 corners of quality

quality

Defining what quality means is difficult. On this subject, the great statistician Walter Stewart stated: “The difficulty in defining quality is to translate future needs of the user into measurable characteriscts, so that a product can be designed and turned out to give satisfaction at a price that the suer will pay” (Shewhart, 1931).

In software development, we tend to focus on a series of defined tests. If all our tests pass, we have developed a quality product ready to be shipped. If the product is shipped and the result is a high volume of production defects, the product was not of good quality.

The challenge with the old way of Waterfall software delivery, and only relying on our tests,  is that the consumer of the product is involved too late in the product development process. The consumer is perhaps the most important aspect of developing quality software.

For this reason, we need to involve the consumer all throughout the development process. This way, we build quality up front.

The below figure shows the three corners of quality model put forth by Edwards Deming.

drawit-diagram-4

What we have learned with the application of Agile, is the importance of learning from the customer. Deming talked about this back in the 1970s, but it wasn’t until the early 1990s that it was applied for software development.

On learning from the consumer, Deming writes: “The main use of consumer research should be to feed consumer reactions back into the design of the product, so that management can anticipate changing demands and requirements and set economical production levels. Consumer research takes the pulse of the consumer’s reactions and demands, and seeks explanations for the findings” (Deming, 1982).

What Deming describes is exactly what takes place during the Scrum sprint reviews. During the sprint review, we show production ready software to the consumer. The consumer can then give immediate feedback. This allows us to make changes to the design of the product.

The old way of delivering software looked like this:

drawit-diagram-5

The new way of delivering software using Agile ensures we build quality into the product up front. We build production ready software in short iterations, then review it with the customer. The new way of delivering software looks like this:

drawit-diagram-6

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

To contact us about our services, click here.

 

 

 

 

 

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.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén