But we are “Agile”

I’ve heard that phrase many, many times.  Usually it’s used to justify not following the current processes, like mashing sizing and grooming together instead of having separate meetings, or making changes to a story after it’s partially (or fully) developed.

Developer:  The change you are asking for will require re-doing most of the development already done this sprint.  We’ll need a new story for this that we can work on in the next sprint

Product Owner (or any business lead):  But we’re agile, we should be able to make this change now.  You are already working in that part of the code…

It seems like being “Agile” is synonymous with not having to follow a defined process to some people.  In my opinion, this couldn’t be farther from the truth.  Agile works best when you strictly follow your process. Always, no exceptions, ever.  I think that’s worth repeating: Agile works best when you strictly follow your process. Always, no exceptions, ever.

Why?

Notice that it says your process. I’m not suggesting to follow some process in a book somewhere.  Follow the process Your Team created.  Assuming your team is following agile practices, the team has developed a very good process that works best for them, and is constantly reviewing and making improvements. If the business goes around the process, then the team is being robbed of the opportunity to improve it.

If having separate grooming and sizing meetings is too slow – isn’t it too slow for all of the other stories? If changes are needed after development is started, wouldn’t it be better to figure out why we have these late changes and how to avoid them?

It’s better to bring up the cases where the process is not working well and fix it for all stories/projects, not just the special ones.  If the process isn’t fixed, you’ll have to keep going around it every time you have tight timelines (or whatever the reason for breaking the process).

Agile works because it makes it very obvious when part of the process isn’t working well.  Everything is done in very short cycles – grooming, sizing, sprint planning, and retrospectives all happen every single sprint (if you are doing it “right”).  If it doesn’t work well, it doesn’t work well all the time.  People get tired of the process failing and will find a solution quickly.  If the pain is alleviated by not using the process, there is no motivation to fix it, so it stays broken.

My suggestion:

Follow YOUR process religiously.  If it doesn’t work well for something, fix the process, don’t avoid it.

Then, when this same type of issue happens again – your process will handle it. Sure, it might take a couple iterations to find a process that works, but you’ll be on the way to success.

 

Agile Mindset

Starting an agile project with a new team

At the first job where we were trying to do agile, none of us knew a lot about what that meant.  We didn’t break down our work into stories, therefor we didn’t estimate any stories.  We simply divided up work that needed to be done among the pairs and did pair programming and test driven development.

Then, the next job where I was doing agile, we didn’t estimate our stories using story points.  We estimated in hours, kind of.  We used a set of hours that we could pick from, it was either 1,2,4,8,16,32 or 64 hours.  This allowed us to stop fooling ourselves that we could be very accurate in estimating a task that was going to take longer than a couple of hours.  In order to determine how much a pair could accomplish in a sprint (which were one week long), we simply found 32 hours worth of work and BINGO.

In my current job, I am trying to bring more agile processes to bear.  I am in charge of a new project at work and have decided to run it in a completely agile manner.  I am the scrum master (which I have only kind of done before, mostly for myself).  The project has only one developer resource.  We have access to a QA resource as well as our user experience designer, though neither of them have any dedicated cards.

The developer on this project is a contractor who is not familiar with the code base, nor with the system that we will be integrating with.  We have not worked with him before.

Our first task was to introduce him to the project and then estimate the cards that we had created.  Rather than going with hours, I decided I wanted to use story points.  Our scale is 1,2,4,8.  Anything that is sized over an 8 needs to be broken down.

After a long estimation session, we needed to determine what work would go into our first 2 week sprint.  In an existing team this is fairly easy…just look at the average velocity and put that many points in the sprint, adjusting for any absences.  But, what do you do when you have a new team and have no idea what the velocity is?

You guess.

That’s right.  Look at the cards that you want to play and start adding things to the sprint until the team says stop.  Then, make sure your backlog is groomed well so if the team guesses wrong and can pull more work in than they thought, they can pull from the top of the backlog.

If the team doesn’t get all of the work done that they committed to in this first sprint, don’t hold it against them.  The first couple of sprints are learning sprints.  The team is learning the code base.  The team is learning the process.  The team is learning what their velocity is.

After a few sprints you can take the average velocity and start using that to plan out the work.  If your team is consistent with their estimation, and is fairly consistent in their velocity, you should be able to fairly accurately estimate when different features will be complete.

 

Egoless programming == Jerkless Programming

As an agile enthusiast, I am a big proponent of the concept of egoless programming.  Jeff Atwood’s post The Ten Commandments of Egoless Programming sum up the concept quite nicely.

I got to thinking about this idea of egoless programming, and I have a problem with the name.  I really think we should call it something like “Jerkless Programming” or “Considerate Programming”.

The problem I have with the name “egoless” is that it ignores that the ego is not in and of itself bad:

From Dictionary.com, definitions 3&4:

egotism; conceit; self-importance:

Her ego becomes more unbearable each day.

self-esteem or self-image; feelings:

Your criticism wounded his ego.
As we can see, the ego is how you see yourself.  The word “ego” is often used when we mean that a person has an inflated ego (or they think more highly of themselves than others do).  These are the people I want to avoid working with.
The ego allows us to feel good about ourselves when we write good code, clean up technical debt, etc.  I want to work with people who have a healthy ego, and are working to nurture their self-esteem by caring for the code and the team.  If we tried to remove ourselves from our emotions, we would become drones and would have little drive to improve the structure of the code if it were working.
So, please, bring your ego’s to work!  Care for them, nurture them, but be realistic.  Look very closely at yourself in the mirror, listen to feedback and be a considerate teammate.

And so it begins…

This will be a place to post our musings of software development and working in the software development industry.  We are software developers and husband and wife.

About Blair –
I work at a loyalty and incentive company that provides programs similar to what credit card companies have (earn points by using your card, and redeem the points for a variety of rewards). I started with the company early in its’ life, before they actually had a product to sell, and helped build the application platform from the ground up. I have grown with the company over the last 10 years. In the early days we were really focused on getting the application working and adding new functionality – really without regard for code quality, capacity planning, maintenance time, etc. Now we are much more concerned with these things and spend quite a bit of time optimizing for increased capacity, making maintenance easier, etc.
I also helped move the development process from waterfall to an Agile (Scrum) methodology. I’m a strong believer in Agile processes and I’ve been working to improve our processes and empower the team members – which is not always as easy at it sounds (and it doesn’t sound easy).

About Becky-
I have been developing software professionally since 1998.  I have worked in a number of industries using both waterfall and agile methodologies.  When I started working, I simply wrote the code needed to get the job done.  I didn’t understand a lot about good architecture, clean coding, etc.  I sometimes considered myself a ninja coder, because I could sneak in and make the change without disturbing the rest of the code.Nearly a decade ago, I started learning more about agile methodologies, clean coding, design patterns, etc.  I was lucky enough to land a job with a couple of amazing developers who had been practicing these things for a while.  Working with them doing extreme programming really accelerated my learnings and my passion for this approach.
I consider myself a software craftsman now.  I am very passionate about creating quality code that is well tested and maintainable.  I also believe very strongly in the agile methodologies as a way to help ensure that the work that is done is done well.

What’s Covered in this Blog?
We don’t want to limit ourselves to one specific topic, so we’ll have posts about Agile/Scrum, Code Craftsmanship (code quality, clean code) – including examples of what NOT to do, and anything else that we think might be useful to others.