Search results: "agile" Page 2 of 8

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.

The one thing you should stop saying to Agile teams

Let’s face it, Agile adoption is difficult. For people new to an Agile team, especially those who spent decades in the waterfall world, it takes time to adjust.

Agile teams

I’ve been on different types of Agile teams. Some were completely new to Agile, while others were advanced. As I’ve written in my post, the problems with SAFe, the real challenge with Agile adoption is the mindset.

It’s not the standups, retros or demos. That’s the easy part. The struggle is in improving collaboration, changing the way you think, and building trust.

If you are a manager, Scrum Master or coach, here’s the one thing you should never say to an Agile team: “This isn’t true Agile”.

I’ve heard this statement quite a bit, and I’m guilty of saying it myself.

Let’s take a look at the statement, and why you should never say this to an Agile team. What is “true Agile”? Is “true Agile” some destination that once you reach you’ve accomplished perfection among the eyes of the Agile Gods? Are there some absolute rules that dictate whether a team is “true Agile” or not?

I’ll tell you what “true Agile” is. It’s a unicorn. It doesn’t exist. It’s a mythical place we’ve made up in our mind due to insecurity. There is no true Agile and there are no absolute rules that say you’re either Agile or you’re not.

Here’s the problem. When you tell a team they are not “true Agile”, it sends the wrong message and makes them feel inferior. It’s demeaning and demotivating. Teams that hear they are not “true Agile” get frustrated and their confidence goes down.

Agile adoption is about progress, not perfection. If a team is doing their best to follow the principles, and following a framework, then they are an Agile team. The team should hold their head high and feel proud that they are Agile.

In Agile, it’s always about improving.  It’s the journey, not the destination. Listen to advanced Agile practitioners from places like Spotify or Google. They say that they are learning, changing and improving. They have humility.

Another way to think about it is with music. I’ve played guitar since I was little, and I’ve always loved music (who doesn’t?) If someone was new to learning guitar, and they loved playing but couldn’t play much due to their skill set, I would never say they weren’t a “true guitarist”. It’s not about being a “true guitarist”, it’s about making music. It’s the same with Agile teams, it’s about building valuable software, and continuing to improve.

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.

 

What are the best Agile development tools?

Agile development tools

The debate over the best Agile development tools rages on. Tools like JIRA, VersionOne, and Trello all offer different benefits. Some people love the lightweight team focused flexibility of JIRA, while others prefer VersionOne for its program management capabilities.

Long before the popularity of Agile, organizations struggled to find the right software delivery tools. Teams need tools for things like version control, defect management, test cases, reports and requirements/user stories.

It’s not uncommon to find companies using different tools to manage the different aspects of software delivery. For example, they might use Rational ClearQuest to manage defects while using HP ALM to manage test cases. Or they may use SharePoint to maintain documents while using JIRA to manage User Stories and Sprints.

Here’s the thing. There is no right or wrong combination of tools that works for your team or organization. Some teams prefer not to use any tools, and that’s okay. The real goal of self-organized teams is to produce good flow. Good flow means producing quality software that provides value to the business. It should be up to the teams to decide which tools, or lack of tools, works best for them.

 

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.

 

Adapting to change, the Agile organization

Organizations today must be Agile to deal with the rapid pace of change due to globalization and technology. In software development, we have seen how well cross functional Agile teams can deliver value.

Companies that adopt this same level of agility across their enterprise will be well served. I’m not talking about scaled Agile or some framework. I’m talking about organizations that can change and adapt. They are like clay instead of rocks. Agility provides a level of flexibility and adaptability that gives them a competitive advantage.

Below is a short talk from John Kotter in which he discusses the differences between the network and the hierarchy, and how they can coexist. In my view, organizational structures of the future will look less like hierarchies, and more like solar systems (networks).

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.

 

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.

 

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.

 

 

 

 

 

 

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.

 

 

 

 

Top 10 influencers of the Agile software development movement

As a practitioner and student of Agile software development, I am fascinated by those who have influenced the Agile movement.

For fun, I have decided to put together my personal top 10 list of those who I believe have influenced what we refer to as Agile software development. Not only have they influenced Agile, most of them have put out bodies of work that will continue to educate future generations.

For all you Agile gurus out there, don’t freak out about who’s not on my list. You may have your own list which looks completely different. I know every time the the NFL puts out a top ten players list,  I’m usually in disagreement 🙂

Here we go…

10 -Kent Beck

 Kent Beck

Currently working for Facebook, Beck is the creator of Extreme Programming. He was one of the original contributors to the Agile Manifesto in 2001. He is a leading advocate for test driven development (TDD). Beck has published over 8 books on software development.

9 – Mary and Tom Poppendieck

Mary and Tom P

Mary and Tom are a package deal. I was fortunate enough to attend one of their workshops several years ago. Minnesota locals, the two have written together several books on lean software delivery. They helped bring lean production techniques to software development. Together they have had a big influence on the Agile movement.

8 – Jeff Sutherland

jeff_sutherland

One of my personal favorites, Sutherland is the co-creator of Scrum. A West Point graduate and pilot,  Jeff flew over a hundred missions in Vietnam. After his military carrer, Jeff got into software development. He was a doctor at the University of Colorodo school of medicine, and he helped write the Agile manifesto in 2001.

7 – Eliyahu Goldratt

Eliyahu Goldratt

Although his name may not be synonymous with software development, Goldratt has influenced the way we think about systems. Goldratt’s book “The Goal” is a required reading in almost every business school. He’s is known for his teachings on the theory of constraints (TOC) and the critical chain method.

6 – Ken Schwaber

ken_schwaber

The co-inventor of Scrum along with Sutherland, Schwaber is a prominent leader of the Agile movement. Ken has authored many books on Agile and Scrum. Ken founded Agile Alliance and Scrum Alliance, which created the Scrum master certification programs. Ken helped write the Agile manifesto in 2001.

5 – Jim Highsmith

Jim Highsmith

Jim has authored books on software development and Agile project management. He created the adaptive software development model. Jim is respected as a leader in the Agile software development movement. Jim won the Jolt award in 2000, and the Stevens award in 2005.

4 – Frederick Brooks

Frederick Brooks

Brooks is an American computer scientists widely known for his book “The Mythical Man-Month”. In his book he describes the lessons he learned while managing the development of IBMs System/360 family of computers. Brooks law states: “adding manpower to a late software project makes it later”.

3 – Taiichi Ohno

Taiichi

The father of the Toyota production system, Taiichi Ohno was the originator what we now refer to as lean. The processes and principles he put in place at Toyota had a huge influence on lean software development and Agile. Ohno claimed that he modeled the Toyota Production system after Ford, only he removed the waste.

2 – Henry Ford

Henry Ford

Ford is a fascinating American icon. He founded the ford motor company and helped create the assembly line production process. Not only did his assembly line process change the auto industry, it changed the world. Manufacturing would never be the same. What I admire the most about Ford was that he accomplished so much, and he did it all  through sheer determination.  Ford had little formal education, he didn’t graduate from High School.

1 – Edwards Deming

deming

My favorite quality guru, W. Edwards Deming. What I like the most about Deming was that he cared for the line worker. He championed pride in workmanship. He put the responsiblity on management to focus on the system. Along with a 14 point process for quality improvement, he created the PDCA (Plan, Do, Check, Act) method. The PDCA method is exactly what takes place during Scrum sprints (iterations). His processes and statistical control methods also revolutionized the Japanese auto industry.

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

To contact us about our services, click here.

Page 2 of 8

Powered by WordPress & Theme by Anders Norén