Search results: "agile" Page 2 of 7

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.

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.

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.

3 mammoth reasons your Agile adoption strategy is doomed

Over the past decade companies finally realized there’s a better way to deliver software. It’s called Agile. If you work in technology, this shouldn’t be news to you. If you are unfamiliar with Agile, check out the Agile manifesto here. In Agile, the development team delivers software in short iterations. They partner with stakeholders to ensure they are building the right product. The process is faster, more efficient, and more collaborative than traditional software development.

standup-modell1

Companies have caught on to the benefits of Agile. Agile began as an organic evolution of software development. It has now become a top down order. Thou shalt be Agile! Executives and managers order their technology teams to go and “be Agile”. They force people to leave the comfort of their cubicles. They put them in a overcrowded pod with no privacy co-located work space. They bring in coaches and expect teams to become Agile out of the gate.

What is the result of this forced top down order to be Agile? Unhappy teams who give off the external appearance of being Agile, but are far from it. They have daily standups, report velocity, and produce burn down charts. They do all they can to show the leadership team that they have become Agile, and the leadership team buys it.

Here’s the thing:    

Moving from a traditional SDLC to Agile is a huge change. Combine that with the fact that people in general don’t like change and you have a major challenge. It’s more than just a changing processes, it’s changing culture. In an Agile environment, team members need to collaborate. They need to be open and honest. They need to sit near each other. They need to actually talk to each other (what a concept)!

Becoming Agile is difficult for employees that worked in isolation for many years. They may feel insecure about being transparent with their work. They may also be afraid that by being more transparent, they will have less job security. They can be quick to judge or find fault with any new processes introduced. All it takes is one team member who isn’t drinking the Agile Kool-Aid to infect a whole team.

Here are 3 reasons why companies fail when trying to become Agile:

1) They don’t invest – Making the change to Agile is an organizational investment. I’m not just referring to a time and emotional investment (which it is). I’m also referring to the cold hard green stuff. Especially for large organizations, if you want to do this right, you will need to bring in help. You’ll also need to invest in the right tool set like Atlassian JIRA or VersionOne. This is where most companies go wrong. They hire one person to come in as an Agile coach. The coach will try to help for several months. Employees are then sent to a 1 or 2 day Agile training course. 

2) They are not in it for the long haul –  Spotify, Twitter and Yahoo had success implementing Agile. They did so by bringing in coaches, implementing training, tools, and organizing practice groups. Their Agile adoption didn’t happen over a matter of months, the transition took years. Leadership teams need to approach Agile adoption with a long term strategy.

3) They under communicate – Agile adoption is a huge change initiative. When taking on any change initiative, companies tend to under communicate by a lot. It is the responsibility of the leadership team to put a communication plan in place. Employees need to understand why the company is making the change to Agile. They need to know how it benefits them and the organization. Some creative ways to communicate include emails, newsletters, meetings, focus groups, and social media. The communication needs to be happening on a daily basis. Below is a great video on communicating a vision for change. The video is by Harvard leadership professor John Kotter:

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

To contact us about our services, click here.

Page 2 of 7

Powered by WordPress & Theme by Anders Norén