You Need to See It

I am currently working on a project for my job that is not going well. Part of the problem is that I was not given explicit instructions on what people wanted. Instead I got instructions to make something better. I sat down and asked questions about specific improvements that people wanted to see. Then I started putting things together so I could solicit feedback.

The first pass went well and people liked the idea of what they saw. That is actually the wrong response. I really needed people to tell me I was headed in the wrong direction or how they thought my ideas could be improved upon. Now we are getting close to the end of the project and I am being asked, "That is all?" Fortunately I still have some time to get things back on track.

Several years ago, I wrote about "Agile Development." The idea is to show something every couple of weeks and constantly ask for feedback. This experience underscores the importance of constantly showing updates. Even though that is what I thought I was doing, I didn't do it well enough as it is only now that stakeholders are coming to me with new ideas about the project.

I don't think the Agile process should be limited to just software development. It could be applied to any job or chore. Think about teaching your children to do dishes or mow the lawn. You don't send them out unsupervised for hours at a time. Instead you periodically check on the work to make sure it is being done correctly. Early in the process is the best time for feedback as the longer you wait, the more fixing needs to be done. Now for my project I just need to figure out how to create the largest flash in the shortest amount of time.

Revisiting Agile Development

A few years ago I wrote about Agile Development. Earlier this week I had an experienced that reinforced one of its principles: quick iterations. I have a project and have been given six months to complete it. I have another developer helping me and so we are meeting often to work on the deliverables. I thought we had a good start to our plan and sat down with my boss to go over some details.

My plan included installing some new software and migrating hundreds of people to the new system. I knew it would be a tough sell but that is how I planned to incorporate one of the most important goals of the project: world-wide access for all teams. My boss suggested using existing software and making small tweaks to bring teams on-board gradually. Rather than trying to get everyone onto the new software in a big push, we will make minor adjustments to the software that teams in one geographical location are already using. Then we will add another team midway through the schedule. Rather than trying to get the third and final group onboarded to new software that they are not familiar with, we will just copy data from our system to theirs and vice versa on a nightly basis.

My plan is much more comprehensive but runs the risk of being impossible. There is a chance that we will get to the end and not have anything working. This will extend the project for an unknown amount of time and could end up being a never-ending project. The new plan is incremental and allows us to have something to show every two weeks, which is our sprint length. If we are late on any of our deliverables, stakeholders will see the delays as they happen and be able to plan accordingly.

This weeks experience reminded me that even though I know software development principles, there are many ways to put them into practice and some are better than others. I need to remember not to focus on one goal at the expense of being able to get something done.

Software Development Trends

Today I had an experience at work that underscored the evolution of software development. When I was in school working on programming assignments for various classes, there really wasn't a need to use a formal methodology. I looked at the problem, sketched out my algorithm, sat down and coded it. Life was pretty easy but so were the assignments, relative to the projects I am involved with now.

I got out into the software development field and had a team that kept up on all of the latest software development methods and we were one of the leaders in implementing the capability and maturity model (CMM). It worked for us and we were able to create some pretty amazing computer software that was on time and under budget.

Fast forward a few years and I found myself doing consulting for various organizations. As I was a lone coder working on projects, there really wasn't a need to completely embrace CMM. Instead I took what felt good and coupled it with what worked in college. Once again life was easy but my projects were rather small and not very complex.

Eventually I found myself working for a very small software organization in Southern California and was introduced to agile software development. My first thought was that "agile" must have been developed by 3M because you use a lot of sticky notes. It felt like the next evolution of software development and seemed fairly efficient.

Then "the cloud" comes along and the next bit of evolution is needed so DevOps is born. DevOps doesn't replace "agile" but becomes coupled with it. In addition to creating software, a group of software developers gets tasked with writing tools to deploy the software. This isn't a large task for small and simple programs. However bigger software projects requiring large numbers of computing nodes or instances running on such services as Amazon Web Services (AWS) or Goole's Compute Engine (GCE) require a lot more care to ensure the code gets deployed correctly.

In my meeting today we discussed DevOps and whether it should be done by a specific team. The group consensus is that each developer should have a hand in the deployment process and understand DevOps. I wouldn't say we are ready to disband the DevOps team yet as each project needs at least one person responsible for architecting the entire deployment system. However this is a shift from how we have done things in the past and seems to be the next step in the evolution of software development. Of course, now that I have written this down it is obsolete. Tomorrow there will be yet another twist.

Agile Development

There are a number of methods that software development teams can use to help manage themselves. Years ago, teams would create detailed specifications over a period of months and then spend years coding only to discover they had built the wrong product. In 2001 a bunch of successful software developers met at a ski resort in Utah and created the Agile Manifesto. This then spurred a new process where developers would work on small pieces of the product with short release cycles so they could get constant feedback on what they were building. Then product users could provide instant feedback to ensure the development team is on the right track.

My current software development team uses Agile development and so the company hired an instructor to come in and teach a 2-day refresher course. It was interesting to spend a couple of days going through the training material. There were other teams new to the process taking part in the course and it was fun to see their reaction. Some were eager to embrace the method while others were less than eager to change their current development practices.

I have to say that there is one problem with Agile for me. I have a specific skill that requires me to work with a number of different teams. So while there is  about 4 hours a week of meeting overhead for the rest of the team members, I end up with about 12 hours a week of meetings. Considering there are only 40 hours of work during the work week, that means I only have 28 to get useful stuff done. So when someone gets all energetic about Agile, I have to bite my tongue to keep from grumbling too loudly.

I am hoping that the guys that created the Agile Manifesto will show up at Snowbird again, where they originally drafted the short statement, and come up with a way to keep me from going to so many meetings. I'd even provide a couple of lift tickets.