Year: 2015

Responding to Change: If You See An Iceberg, Change Course! Agile Manifesto Value #4

Zan The Basics , ,

Welcome back to my continuing Back to Basics series. This time I’ll be covering Responding to Change: Agile Manifesto Value #4. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Harnessing the Power of Change

In the last post, I talked about the need for collaboration with customers, and how original, fixed contacts stifled flexibility. This is the flexibility I was talking about. As you collaborate with your customers and get their feedback, you will learn things. Sometimes you’ll make small adjustments, but sometimes you’ll find things that require a major change of course. It seems silly, but often people can see danger coming, yet refuse to change course.  Not in Agile. When we see an iceberg, we alter course, and we check course often enough, that even if we do crash, hopefully we can correct instead of sinking.

Everybody’s Got a Plan Until They Get Punched In The Mouth

Like Iron Mike said, everybody makes a plan. However, most plans fall apart as soon as they hit adversity. Even if you try to plan for adversity, you’re going to get hit with something you didn’t expect. So why do we even value planning at all? Well as Dwight D. Eisenhower put it “Plans are useless, but planning is indispensable.”  We plan so we know what parts of the plan can change, and what this will effect. If we don’t plan, we don’t know what’s coming. We have to make a plan, knowing it will change.

Not Just For The Software

More than any of the other values, this one applies more than just the software being created. Being Agile means we need to identify not only changes in plans for software, but for plans in how we work as well.  Setting up a team is an act of planning. We plan for these people to work together on projects. Are we just going to stop if one team member gets a new job and moves on?  As we identify things need to change in the business, we respond by working to ensure these roadblocks are removed.  If we stick to the plan, indulging in the “that’s the way we always do it” mentality, we do ourselves a disservice continuing to do things we know are wrong.  Again, it seems like common sense when we say it out loud, but its surprising just how willing we all are to stick to the plan even when we know its wrong. I could continue to write about that, but there’s no way I could do it better than the book “Who Moved My Cheese” by Dr. Spencer Johnson.  I won’t tell you that you have to read it, but I highly recommend it.

Summing It Up

In Agile, we value responding to change when we find we need it.  We value plans, but more for the act of planning then the actual plan that was produced.  We must always be vigilant that we do not stick to plans just for the sake of the plan.

Did you plan to leave a comment? Respond to more than just change below! Thanks for reading!

Advertisement

Customer Collaboration: No Magic 8 Balls Here? Agile Manifesto Value #3

Zan The Basics , ,

Welcome back to my continuing Back to Basics series. This time I’ll be covering Customer Collaboration: Agile Manifesto Value #3. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Nostradamus Doesn’t Work Here

There is a shortage of functioning crystal balls in the world, and most fortune tellers are more concerned with your love line and your lucky numbers, not telling you what software will work for you once it’s built.  When we talk about customer collaboration, we have to look once again at how projects are traditionally made. With traditional software projects, it turns out you needed all of that comprehensive documentation from value number 2, because how else could you make a proposal to earn the contract for the project?  Contracts needed to spell out exactly what you wanted, because you were going to give it to a company and they would take it, go away for a while, make some magic and poof, its software!  I hope you and Doc Brown came back from the future knowing exactly what you need, otherwise chances are what you’ve asked for isn’t going to end up being what you need, and that’s assuming the magic men making your software are able to return exactly what you asked for with no issues.

With Agile, we value not only our own interactions like back in value 1, but interaction with the people who will be using what is being produced.  We not only want to know what they think they want in the beginning, but we want to work hand in hand with users as often as possible.  As we create, we constantly want customers to work with us, refining their vision of what will be useful based on what’s been created. It may so happen that with a few small changes, the customer may determine they may only need a portion of what they originally thought to meet their goals. Seems wasteful on both parties to continue at that point, doesn’t it? It may also happen that the customers are completely wrong about what they thought they wanted, or a major change in their industry completely invalidates their plans.  Once again, without collaboration, they would receive (and pay for!) something completely worthless.

New Types of Contracts

We obviously still value contracts. After all, from the developer point of view, we want to know we’ll get paid, and how much.  However, we now value new types of contracts, which allow flexibility and collaboration to ensure useful software is created and time is used efficiently. Contracts based on time and materials, flexible contracts with out clauses, and contacts based on incremental delivery are just some of the new forms of contracts that have come out of the Agile movement.

Summing It Up

Working software is only half the battle. Working software that doesn’t do what’s needed is less than useless, it is costly and wasteful. Comprehensive contacts are far more likely to produce software that doesn’t do what’s needed.

Working Software: Much Better Than Software In Paperwork. Agile Manifesto Value #2

Zan The Basics , ,

Welcome back to my continuing Back to Basics series. This time I’ll be covering Working Software: Agile Manifesto Value #2. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Working Software: Just As Simple As It Sounds

In Agile, we value working software. That sounds like a no-brainer, right?  Who doesn’t value working software? Taken out of context, this doesn’t really tell us much. So lets contextualize it. If we value working software, then we infer that we do not value software that doesn’t work. Taken to its logical conclusion, software is only valuable once it works, or in other words, once it can be used.

Now to the layperson, you might be tempted to take that to mean that software is only valuable once every single feature is complete. After all, how can you use software that’s not complete?  Let’s examine that. Take your favorite piece of software. For our example, let take a word processor like Microsoft Word.  Microsoft Word has loads and loads of features, some you might not even know existed (for example, Word can convert a table to a graph without any external software. Who needs Excel?). How many of those features do you actually use when you’re writing a document? Could Word be valuable, even if all you could do is type words, or type words and print? Sure it could, that’s why Notepad exists.

So what is “Non-Working” Software? Well, that’s a little bit harder of a concept. After all, code will generally run when executed, and a database exists once you create it, right? Here’s the “Tree Falling in the Forest” question for that: If a database exists, but nothing is connected to it, is it really working? What is more valuable, one table connected to an input form, or 100 tables connected to each other and nothing else?  All this is not even getting into testing, ensuring that your “working software” actually works like you think it should.

Comprehensive Documentation

Beyond the context I talked about above, the Agile Manifesto contextualizes this value in contrast to “Comprehensive Documentation”.  Let’s examine why.

It’s important to remember that the Agile Manifesto was not created in a bubble. At first, software projects were treated like every other kind of project: write out all the requirements into “Comprehensive Documentation”, and then complete each stage of creation as a discreet step, for example design then develop then test. There was only one problem with this. It didn’t work. Development took so much time to match the features, and when it couldn’t the documentation needed to be updated. Testing got pushed so far out, there was no time to actually develop fixes for bugs. Even if you did complete all the features you documented, there’s no guarantee what you created is useful, since you took a year to finish everything. The world can change in a blink of an eye, and while you were away building all that comprehensive documentation, Google came by and already did it faster and better.

Projects do not need to be documented up front. Some projects don’t need more documentation then commented code and a list of user stories. Agile says its always better to create what you need now than what you think you need someday, and that includes documentation.

Summing It Up

With Agile, we value something tangible that works, as opposed to a theory that might work. Even if your “working software” doesn’t end up being the real solution, the sooner you find out, the better.  Anything that is not real is still imagination, and its really hard to use imaginary software.

Like what I’m saying? Don’t like it at all? Leave me a (working) comment below!

Indviduals And Interactions: You Mean I Have To Talk To People? Agile Manifesto Value #1

Zan The Basics , ,

Welcome everyone to the first in my Back to Basics series: Individuals and Interactions: Agile Manifesto Value #1. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Individuals

It’s easy to look at a company/department/team as a box or machine. You input the instructions and materials(most often money) and out comes a product. Of course, this is not really the case.  What ever this group is, it is made up of individuals. With Agile, we value each individual for all of their real and potential contributions. Without the individuals, the group does not exist, and nothing can happen.  Humans are not resources, and shouldn’t be treated as such. However, individuals working alone can only get you so far, which leads to…

Interactions

Interactions are fun. Much like chemical reactions, we take individuals, and mix them together. The results can be mundane, or they can be amazing, or even explosive!  This stems from a single idea: communication is the key to success. The frequency and value of interactions and communication between individuals determines just how good any output from said individuals will be. If your people don’t interact, then no reactions can take place. If people do interact, then as with chemistry, the whole can become much more than only the sum of its parts.

Interaction Killers: Processes, Tools and the Oxymoron of “Agile Processes”

So if we value the interaction of individuals, what does that have to do with processes and tools, and why do we value them less? First off, let’s be clear: there is still value in processes, and there is still value in tools.  However, when processes and tools interfere with individuals interacting, the processes and tools lose their value.  Let’s take some concrete examples. Jira, RallyOn and the like are great tools. Many an Agile team have used them to great success. However, if a team were to allow these tools to interfere with interactions, say by using task tracking in place of speaking face to face, the tool looses its value. Strictly defined processes, the cornerstone of the Waterfall SDLC, can destroy interaction, as we continue to act on others instead of interacting together.

So what is an Agile Process? I’ve seen it stated that there are no “Agile Processes”, only Agile teams and the environment for the Agile team to be Agile. I believe that teams will come up with their own processes internally, and if done with an Agile mindset, these processes will define how that team is Agile. There is no one size fits all process that will make a team Agile. Even Scrum, the most popular incarnation of Agile in software, is just a framework. It’s a restrictive framework which enforces the values of Agile (including Individuals and Interactions), but the processes the team comes up with to be Agile are their own.

Summing it up

Agile values the interactions of individuals over anything that will cause interactions to be interfered with.  There are great tools and processes out there, but if they interfere with people working together as a team and interacting, they can be damaging.

Want to interact with me? I welcome your feedback. Leave me a comment!

Back to Basics: The Agile Manifesto and The Principles Therein

Zan The Basics

OK, so I’ve been doing this blog thing for about a week now.  I’d say it has gone pretty well. I’ve got a few posts under my belt and even gotten a bit of positive feedback. So I figure now is as good a time as any to go back to basics and perform what is probably a rite of passage for all Agile blogs: covering the Agile Manifesto and its 12 guiding principles, while remixing it a bit with my own input, anecdotes and opinions. Well, maybe it’s not a rite of passage, but let’s do it anyways.

Over the next, oh let’s say 1 or 2 weeks, I’ll make a series of posts about each of the value areas of the Agile Manifesto, and each of the guiding principles of Agile. But before we get into the nitty gritty, lets look ahead to where we’re going, and take a look at the values and principles of Agile, all courtesy of The Agile Manifesto.

Values

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

That is, while there is value in the items on
the right, we value the items on the left more.

A pretty clear list, if I do say so. One important thing to note, is that the existence of value in all of these items is not disputed. There is value in everything on the right, but the items on the left will be more valuable. We’ll get into why as examine each item more in depth in it’s own post.

Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Well, that is quite a list. Each item is a powerful statement in and of itself, many with multiple nuances leading to different practical applications within the Agile world.

This will be a lot of ground to cover, so stay tuned and stay patient, and thanks for reading!

Coming up next: Individuals and Interactions

Zan’s Weekly Challenge 7/27/15: Own Your Goals

Zan Weekly Challenge ,

Hello dear readers!

It’s time for a new feature here at the Zan-gile Methodology! Weekly, I will pose a challenge to help spur your thoughts, strengthen your skills or open your mind to new possibilities on your Agile journey.  While I have no way of following up with most of you regarding these challenges, I welcome you to post your feedback as a comment, send me a tweet @zandterman, or even send a smoke signal or carrier pigeon!

This weeks challenge: Commit to your goals completely.

Some tips to help with this:

  • Watch your language: Use firm, strong language when speaking of your goals. Say “I will” instead of “I plan to”. Don’t hedge on contingencies. Speak your goals out loud, either to your team or to yourself, using clear, simple terms.
  • Have SMART goals: SMART stands for Simple, Measurable, Attainable, Relevant, and Timed/Time Boxed. Make clear goals which you can complete, which you will be able to determine is complete, in a certain amount of time, that will provide some sort of benefit.
  • Be honest and true. If you don’t complete your goal, own it. Examine why this happened. Find areas to improve. Was your goal really SMART? If you did complete your goal, was it too easy? Can you challenge yourself further next time?

Please let me know what you think of this challenge, and if you have any ideas for future weekly challenges!

I just want to tell you, good luck. We're all counting on you.

Where Should We Go For Dinner? Decision Making and the Fear of Rejection

Zan Team Dynamics , ,

i-dont-care-restaurant

We are all faced with decisions to make every day. Paper or plastic, regular or decaf, what’s for dinner… so many choices. When we’re alone, we take into account our own feelings, bias and knowledge, and usually come up with some kind of action or response, often because we have to or that guy who really needs a coffee is right behind you.  However, once you start adding other people to the decision making process, things start to get muddy. Take, for example, the classic dinner conversation:

Person A: What do you want to get to eat?

Person B: I don’t care, whatever you want is fine.

A: I dunno, either, that’s why I asked you. Well, what about Pizza?

B: Nah, I don’t feel like having pizza.

A: Oh… OK. Well what do you feel like?

B: I dunno, you pick.

I’m sure just about everyone has been on one side or the other of that conversation.  The thing is, this conversation happens all the time in every group of people. Observe:

Teammate 1: I propose we spend an extra hour each week doing research on new methods of data access.

Teammate 2: I’ll go with whatever the team says.

Teammate 3: Doesn’t matter to me.

Teammate 4: I agree with 2.

Teammate 5: <Crickets chirp>

And so on and so on…

So what happens here? Well, either the team goes with the suggestion, based on one person’s input, or no one feels strongly enough about something, so the question lingers. Let’s look at what can happen in these cases:

  • The team goes with the suggestion, and they like it: The team will be more willing to go with the suggestions of Teammate 1 without thinking critically about it. The team has given up ownership and self-organization to one member. Teammate 1 may feel the burden of being “the guy/gal with the ideas”, and stress over needing to come up with all the plans.
  • The team goes with the suggestion, and it fails: The team can engage in finger pointing at Teammate 1, after all it was his/her idea, and I never said I actually agreed. Teammate 1 feels called out, leading to rifts in the team, or causing him/her to withhold new ideas from the team, even if they’re good. Other members of the team see how Teammate 1 was treated, and are now wary of putting their ideas out there.
  • Lacking motivation, the team maintains the status quo: If there was a potential issue, it continues unaddressed. Teammate 1 is left in limbo, unsure whether to push forward with his/her idea, or to drop it. Teammate 1 feels disrespected, since no one was willing to consider his/her idea long enough to form an opinion. All teammates recognize group apathy, and choose not to share new ideas.

For Agile teams who want to be high-functioning, this is a major problem. There is a lot of psychology behind why, as humans, we prefer not to make decisions. You can find that on the web, so I’m not going to go into that here.  In my experience, however there is one major force in play:

Fear.

People fear giving their opinion.  By giving an opinion, you open yourself to rejection. You open yourself to conflict. You open yourself to looking weak because you are ill informed. And you open yourself to the worst thing ever: the possibility of being wrong. Nobody wants to be wrong. When you are wrong, it’s even harder to admit it. Sure there are other possible reasons, like a lack of respect for the questioner (so much so that you can’t be bothered to have an opinion), or being too distracted to answer fully (generally better to state as such), but generally when faced with a normal decision to be made, if we choose not to give our opinion, it is out of fear.

People feel like by saying “I’ll go with the team” they’re providing tacit approval to ideas their teammates come up with.  In reality, all they’re doing is passing the buck and hoping someone else will do the thinking for them.  It’s a disservice to the the both the person asking, and the person answering.

So what do you do if you really don’t have an opinion? Well, communicate and negotiate. For example, “I don’t really understand what an extra hour of research will do for us. What do you think we have to gain from this?” Once you understand the question, do your teammate the service of giving your honest opinion.  If you disagree, have an open and honest conversation as to why. If you really agree, give a firm agreement, and stand behind your statement.  Nothing is gained by delaying conflict if it needs to happen, and much can be lost if feelings are hurt.

The best thing? You can apply this anywhere! Let’s look at the ideal way of handling the “Dinner Problem”.

Person A: What do you want to do for dinner?

Person B: I hadn’t really thought about it, do you have any suggestions? What do you feel like having?

A: I don’t really want anything fancy, quick and easy for me. What about you?

B: I’m still not really sure what I feel like having, can we go somewhere with a lot of choices?

A: Quick, easy and lots of choices? You know, there’s that food truck night at the local school tonight, why don’t we go there?

B: OK, I can agree with that. Sounds like an adventure!

Well, that seemed a bit too easy, maybe we can dream about that last one…

Paint the Fence, Daniel-San: Thin Vertical Slices and the Economy of Movement

Zan Analogies ,

paint-fence

I’m not the first person to equate Mr. Miyagi’s method of teaching Karate in “The Karate Kid” to Agile. Jeff Gothelf equated Miyagi’s use of rote repetition and skill mastery to Agile and Lean UX. Ed Wong gave a talk to his Scrum User Group about how the learning from an expert is very similar, whether its Scrum or Karate. I’m sure there are many more out there. Continuing on that thread, I’d like to look at this in the context of story splitting, different methods of ‘painting the fence’ and how rote repetition can allow us to improve our skills and apply them in new and unfamiliar ways.

In this particular example, the fence is a section of our project. It’s clearly defined, relatively uniform, and can be painted with many different methods. Each board in the fence is a feature.

A poorly drawn blank fence.I’m not very good at art…

If we were painting via waterfall, we’d be painting horizontally, applying changes across multiple features. We would get a certain distance, and then need to come back, painting more parts of these features,

FenceHoriz1 FenceHoriz2 FenceHoriz3

Look at how much work has been done here, and nothing is even halfway complete. Some planks couldn’t be painted in the same way, since they weren’t uniform. What happens if we want to change colors? Or pull out some fence posts? We might have a vague idea of what a finished product will look like, but nothing concrete. All of these features are linked now, to finish, we really have to finish them all.  We might have saved a little energy by not having to switch levels as often (front end, back end, database, etc.), but we wasted a lot more going forward on features, then going back and touching all those features again.

On the other hand, lets take a look at the way Agile would have us do it, in thin, vertical pieces, or in our examples, plank by plank.

FenceVertical1FenceVertical2FenceVertical3

Here we see each plank completed on its own. Irregularities in size or composition no longer create issues. We can see what a completed post looks like, and extrapolate what the fence may look like once complete. If we decide to make changes, it is easier to adjust or remove completed work, while maintaining uniformity. We may move up and down more often, but we complete more often, and we reach more natural stopping points to review our work. As our muscles(skills) in this area improve, we become more efficient at this vertical movement, needing to expend less energy to do so. The smaller the slice, the less energy we have to expend to complete it.

Once we are efficient at doing so we can then apply these skills to other areas, even areas which are unknown to us. Just like when Mr. Miyagi had Daniel apply his fence painting skills to blocking, we can now look at a new project, find the features and apply all of those now-engrained skills, and flex our agile muscles. You can also begin to work on new skills, such as refactoring and communication or punching and crane kicks.

So get out there, and paint those fences!

The Agile Master

Zan Questions , , ,

Catchy? No, I’m not proclaiming myself a master at Agile… actually I wanted to pose a question. In Scrum, there is a role called the “Scrum Master”. It’s very unique, and it speaks to what that person is all about. They will (in a manner of speaking) master the Scrum. Not the Scrum Team, but the Scrum itself. They facilitate, lead, coach, and in general do what needs to be done to facilitate the Scrum for their team, so that the team can focus on delivering value.

However, once you get outside of Scrum, does that person disappear? Just because you’re running some other Agile flavor like Crystal or Lean Software Development (maybe supplemented using Kanban to control work-in-progress) on a DevOps team, does the need for a “Scrum Master”-like person disappear? The most common title I’ve seen is the “Agile Coach”, which is a great title as well. One of my favorite books (indeed, my coaching bible) is Lyssa Adkins’ Coaching Agile Teams which uses Agile Coach as the title of this role. However to me, “Agile Coach” can be both too narrow and too broad of a description or role. If only interacting with a team, this person does far more than coach. Like the Scrum Master above, this person will not only coach and teach, but facilitate, remove impediments, resolve conflicts, and solve problems. On the other hand, I’ve seen Agile Coach thought of and described as a coach/mentor for a group of “Scrum Master” like people, be they actual Scrum Masters on Scrum teams, or other such facilitators.

There is a distinct difference which seems to go unaddressed. Scrum Alliance makes a distinction between the Scrum Master/Scrum Professional level and Scrum Coach/Scrum Trainer level of certifications. Scrum.org does not, but they do make a distinction for experts which they list on their site.  Agile as a discipline at large does not seem to do so. Scrum Master sounds focused, Agile Coach is kinda nebulous, and doesn’t speak to your team’s discipline.

Maybe we can just add “Master” to the flavor of agile your team most closely resembles? That sounds fun!

  • The XP Master! World of Warcraft here I come! Or, a Windows guru from last decade.
  • The Lean Master! I can lean at any angle! 30 degrees, 32 degrees, you name it! (OK I know it’s supposed to be bend, bite my shiny, metal… ahem.)
  • The Crystal Master! New age hippy, or reject boss from the Legend of Zelda series?
  • The Agile Master! I don’t know, sounds like it outranks a mere Coach…

At the end of the day, it doesn’t really amount to much, mostly semantics and curiosity. As with many things, I don’t know the answer, I just pose the questions.  What do you think? Leave me some comments!

Introduction: The Zan-gile Blog

Zan Introduction ,

Hello, and welcome to my brand new, fresh out of the box, Agile blog: the Zan-gile Methodology!  I know, I know, clever name, right? I’m sure you’re wondering “Zan, why are YOU making an Agile blog? Aren’t there like, approximately, 37 million Agile blogs out there? What can you offer?” And I say, “Read on, hypothetical reader, let’s talk about it!”

Let’s start right away and say I’m not here to bring about big, sweeping changes in the world of Agile. That would be foolish for many reasons, not the least of which being that I believe incremental changes are generally a better idea.  So don’t let the title fool you. I haven’t come up with some silver bullet, magical one-size-fits-all solution. I am simply a huge fan of the Agile Methodology, and I look to live it and love it every day.

“We are like dwarfs sitting on the shoulders of giants. We see more, and things that are more distant, than they did, not because our sight is superior or because we are taller than they, but because they raise us up, and by their great stature add to ours.”

Along my Agile journey, one of my biggest sources of inspiration and knowledge have been blogs. Some were written by huge names in the Agile world, such as Alistair Cockburn, Martin Fowler and Mike Cohn, and some were much smaller such as micro-blogs posted on the Scrum Alliance website, LinkedIn and their ilk, and many more in between. Many I have learned from, some I have disagreed with, but all helped me form myself into the ScrumMaster and Agile Coach I am today, and will continue to grow to be.

This blog may serve as no more than a place for me to collect my thoughts and organize them so that I may refer back to them to see how far I have come. If that is the case, I am content. However, if I can deliver value in such a way that even one person may read my blog and come away with new knowledge, a fresh perspective or even a hunger to research to disprove my opinions, then I will be both infinitely humbled and extremely gratified.

So with that I say. thank you for taking the time to read my thoughts. I crave your feedback, so make some comments!  Look for more content soon!