Author Archives: AdamM

About AdamM

I have been a software developer since June 2008. Before that I spent almost 5 years working my way from part-time computer support to Systems/Network Administrator & IT Team Lead of a 500 person multiple campus company. Before that I did 2 years as a phone support technician. With over 12 years of IT industry experience spread across both system administration and software development I see IT in a broader scope than most. Now I am becoming something more. I am an Agilist. I am moving on to project management. I am pushing positive change within my team, group, and company. I am looking to provide the best solutions for delivering the most value to organizations in the shortest practical time. I believe that even as I move from implementing Agile to teaching Agile to others I will never be done learning it.

Before You Can Customize You Must Standardize.

I like to point out that Agile is going to look different from one company to another. In fact, it often looks different from one team to another. To get the most from an Agile transformation there needs to be freedom for the teams to adapt. This isn’t the whole story though.

Best Practice Signpost Indicates Better And Efficient Procedures Stock Photo

Stuart Miles – FreeDigitalPhotos.net

Just as humans must walk before they run teams must start along an Agile path before they can create their own trail. It’s a truth that has been known for ages among many specialties over time. The most common reference is to Shuhari. The basic premise is that you start by imitating what someone else does. You then progress to modifying it to better suit your situation. You end the end up as a master that can create new ways of doing on your own. This same logic applies to attempting an Agile transition in a company. Whether the pilot program or the last team on board the truth is the same. Continue reading

Thoughts on Scaling

There is a lot of work being done on scaling Agile. This makes sense. There are few people anymore that will argue against Agile methods on a small-scale. The problem is that many organizations are not small. Plugging these small-scale changes into the greater organization can be difficult and often has mixed results.

Editor Adjusting The Sound Mixer

stockimages – freedigitalphotos.net

Any organization looking to scale needs to know why they want to scale. They need a plan to scale. They need a way to evaluate whether their transition is working.

A good way to think of what’s happening is by imagining a city skyline. Spreading Agile to all teams is equivalent to building more skyscrapers across the horizontal landscape. Scaling Agile in the organization is more like extending the existing skyscrapers higher in the vertical plane. The analogy isn’t perfect of course. Scaling will require more horizontal involvement and spreading will require a degree of vertical integration. The important part is the focus and most movement is in a different direction scaling than it is for spreading.

Continue reading

The Yearly Stall

We’ve all been there. Here in the Northern US it happens like this. It’s the dead of winter. The days have been getting shorter and darker. The weather has been increasingly trapping us inside while simultaneously making our daily commute longer than ever. January first approaches and we make some resolutions, providing focus and hope. We work hard towards these new goals. We see some positive change. Progress is made and it makes us feel good. Then something happens.

Baby White Tiger Laying In A Mattress Stock Photo

anankkml – FreeDigitalPhotos.net

Sometime in late February or early March is when we tend to first notice it. We’ve lost momentum. Progress has stalled, and we aren’t really sure when it happened. We might have lost the initial progress. In some cases things have slid even further back then when they started. Most of the time by May it’s as if nothing ever happened.

Many Agile transformations are the same way. They start strong. Everyone has really good intentions. A couple of process changes are made. Some benefit is seen. Some resistance is met with facets of change that are uncomfortable. Concessions get made. The result is little change, minimal benefit, and stalled change initiatives. Continue reading

Don’t Solve Every Problem

This is hard for me to say. I like to solve problems. Most people reading this also like to solve problems. It’s in our blood to fix what’s broken, improve what’s inefficient. It can also be a mistake.

Tug Of War Between Two Girls Stock Photo

meepoohfoto – FreeDigitalPhotos.net

I’ve talked about this before. At the start of the Back to the Basics series I posted about Tensions to Manage. I’ve thought about this topic more lately as I’ve read about the shift in attitudes towards estimation. The desire of strategic decision makers for estimates is a tension at odds with the desire for the Agile Team to concentrate on the now. The solution doesn’t lie in eliminating all estimates. Likewise the solution doesn’t lie in forcing the team to do detailed estimates for everything. The solution is to manage the tension, not give a final answer.

These situations are common in an Agile transition, especially in the early days. To maintain our sanity as coaches we need to realize that not all problems need to be solved immediately. Continue reading

Agile In A Small Team

Scrum states that the right size for a development team is 3-9 people. I have seen that when teams are larger than this they tend to break themselves to smaller sub-teams. This lowers the risk of attempting Agile with large teams, and if managed properly can make it easier by effectively replacing the larger team with the sub-teams officially.

Two Men In The Office Stock Photo

patrisyu – FreeDigitalPhotos.net

When teams are smaller than this it may seem nearly impossible to properly “Do Agile.” An important thing to remember right off the bat is that Agile Is Not Scrum. It’s also worth remembering that Agile is a journey.

Take Pair Programming for example. It either is or is not happening. There are different ways of doing it. It can be tweaked a little over time. At the end of the day though, you either are or aren’t Pair Programming and if your process doesn’t change neither does that fact.

Agile is not like that. There is no end state where you can say you are Agile. If you think you’re at such an end state you have succeeded in no longer being Agile. Being Agile, or working with Agility as it were, requires the ability to change. Being Agile means one will constantly be open to inspection and adaptation. A static end state is completely at odds with this concept. Continue reading

Agile Requires Change

Change Ahead Sign Stock Photo

mrpuen – FreeDigitalPhotos.net

I spend a decent amount of time pointing out that every Agile Journey will look at least a little different. I appreciate frameworks such as Scrum. Having a defined process to follow generally makes the initial start of a transition much easier.

In the last post I pointed out that change has to start somewhere. In fact, I would state there is no Agile Journey without change. Being Agile is deeply rooted in responding to change. It’s one of the main values from the value pairs. An Agile journey with no change is as useful as a cancelled cruise is fun.  Continue reading

Start With One

3d ManStanding Under Direction Board Stock Image

digitalart – FreeDigitalPhotos.net

We all played at it when we were younger. “If you were stuck on a deserted island and could only bring one person/item/food what would it be? As we prepare to enter the new year I thought I would ask a similar question. If you has to start down the path of Agility with only one process what would it be? This isn’t about what one value pair or principle you would follow. As an Agilist I hope that your preferred process does line up with one, but that’s not the point. All change has to start with something. If you were only allowed to do one change at the outset, what would that change be?

Maybe you would start with iterations in hopes of rapidly delivering value to your customer. Perhaps your first order of business would be to change your teams so that developers, testers, and business representatives are working together on product teams instead of separately on functional teams. It may be time for you to bring your product team and your customer together for some direct interaction.

Whatever the single step you could take is you should move forward with it. Every team and situation is different, and as such there are multiple right answers for what one thing you should start with. As a coach or agile change agent you may have a favorite that you lean towards starting with. I’ll be back after the new year to talk about my preferred starting point and why. In the meantime, feel free to share your preferred starting point and why.

Sustainability

Working Team Celebrating Stock Photo

Ambro – FreeDigitalPhotos.net

The Agile Manifesto has important things to say throughout for any time of year. As Agilists we should seek to embody it whenever we can. We should allow it to guide our thinking, decisions, and actions at work.

While the Values are at the core of the manifesto, the 12 principles are important to know as well. This time of year is a good time to focus on one part in particular, sustainable pace.

The actual text from Agilemanifesto.org is:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Because I believe Agile principles and practices can apply outside of software development I like to think of sustainable pace versus sustainable development. They should be thought of as having the same meaning.

Classic software development is thought of having a “death march” at the end. This has been true for some teams in the past, but is not a given. The idea of the march is that a large amount of stuff is butting up against a final deadline and has to be working no matter what. The causes are varied and not relevant to this post, but that it happens is.

In Agile we make small bits at a time. There can be no death march because there is no large deliverable to slowly creep to a long away deadline. There is a deadline coming soon, and a small amount of stuff to be done by then. Right after that will be another near-term deadline with a small amount of stuff to be done by then. If there is a “mini death march” as we come up on one deadline, less stuff is promised for the next deadline.

One advantage is sustainability. By eliminating the death march we save our people and allow them to perform better more often. Without a death march looming over them the people on the tea will have no problem continuing to deliver.

During the holidays that need for sustainability becomes stronger. People are under stress from outside influences. Their friends and family are demanding a little more time than they normally would. Their ability to commit at work may be impacted. An Agile mindset allows us to continually adjust our commitment and maintain sustainability for every member of the team.

Do you account for outside factors as you plan future iterations? How could you start?

Automation and Agile

Cogs Stock Photo

Michelle Meiklejohn – FreeDigitalPhotos.net

Almost every time you hear about how to become more Agile automated testing comes up as a must do. The natural assumption might be that automated testing is required for a process to be Agile. If a team doesn’t use automation they feel they cannot be Agile, so why bother trying?

I have read the Agile Manifesto many times. Of course the value statements wouldn’t have anything this specific. I’ve read the 12 principles many times as well. I have never seen where the manifesto or the underlying principles require automation in any form. Continue reading

Red Flag: Powerless Product Owner

Red Warning Flag On Beach

Stuart Miles – FreeDigitalPhotos.net

Every attempt at transition can have issues. Some issues are fairly common regardless of who attempts the transition. No matter who tries to cross the Sahara there will be a lack of water available during the trip. These common issues are often called red flags.

Every desert crossing attempt is unique. The people and methods involved vary. Some may be making the trip over the course of week, others in just a few hours. In each of these circumstances the best way to address the lack of available water is very different.

In Agile transitions there are also red flags. Just as with crossing the desert each Agile implementation is different. As such there is not a proper way to address every issue every time. The more similar organisations are the more similar the solutions may be, but even that is not a given. Today we are looking at the Agile red flag of a Powerless Product Owner. Continue reading