Still Not Agile? Take Baby Steps

It’s 2014 and you still aren’t Agile. You haven’t had the luxury of upper management taking the lead and you don’t see any signs of that changing. How do you get started with Agile?

If you have management support then bringing in an Agile coach is a really great way to kick things off. You’ll have an expert to guide you and answer all of your questions. You’ll also have someone constructively calling you out on your unproductive habits. However, if you don’t have this option then the second best approach is to gradually work it in from the bottom up.

If you haven’t already, make sure you read the Agile Manifesto and the Principles behind the Agile Manifesto. Spend some time reading up on the purpose of the various ceremonies in Agile Scrum. I recommend Scrum because it’s the most widely practiced flavor of Agile, and it’s fairly prescriptive.

Trying to introduce all of the practices immediately will likely be too overwhelming. Here are three things I recommend you try first as they will add standalone benefit to your process, even if you never adopt all of the recommended practices.

Document Your Work and Make It Visible

Think of everything you are currently working on and will be working on in the coming months. Break that work into reasonably small units, say less than five days of work per item, and document each item on an index card. Write down just enough information that you will know what you are referring to if you look at the card a month from now.  This can be a team or individual effort depending on your situation.

Next, draw three columns on a whiteboard (or something comparable) and label the columns “Backlog”, “In Progress”, and Completed”. Now divide up the index cards into these three self-explanatory categories and tack them on the board. Congratulations. You now have an “information radiator” that broadcasts your current and upcoming priorities. Anyone can walk by and see what you are working on, and what you having piling up.

This is a useful enough tool for keeping track of your own work that it doesn’t necessarily need to be seen by others. However, people will look at the board. If you are lucky, a customer or your manager  will look at the board and ask you a question or two. “What does card XYZ mean? I didn’t know you were working on that.” or “I thought you were working on ABC, is everything OK?” These are good conversations to be having as they can help ensure that you are working on the right thing. Communication is key!

The board is also a useful tool for prioritization. When someone swings by to ask you to work on something you can grab a card, stand up, and have a constructive conversation about which of the things in your “In Progress” column should get moved out. After all, you can only work on so many things at once.

Daily Stand-up Meetings

Having a daily stand-up meeting is a surprisingly effective way to kick off the day. It is also a step in the right direction when it comes to frequent communication! Try to include everyone who is a regular contributor to the project. At a minimum, this should include the other developers and QA. In a perfect situation this will also include the Product Owner or customer, as well as any other cross-functional members of the team (e.g. UX Analysts,  Operations, etc.) that might not be 100% dedicated to your project.

I won’t go into all of the merits of a stand-up meeting as there are plenty of great resources on the topic (see Wikipedia for example). While you should be communicating with your team members in near real-time, a stand-up meeting guarantees you are communicating at least once a day.  This can be especially beneficial for getting some face time with a Product Owner or your customer, who may not be as integrated with the team as you’d like.

Retrospective Meetings

One of the principles behind the Agile Manifesto is that the team should be continuously improving. It states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Having a regularly scheduled retrospective meeting provides team members with an opportunity to talk about what is working, and what isn’t. As with stand-up meetings, you shouldn’t necessarily wait until this time to bring ideas to the table, but it does provide a guaranteed time slot to ensure you are devoting at least some time to continuous improvement.

In your first few retrospectives you’ll likely be talking about how to make sure the stand-up is adding value, whether you want to add another column to your board (e.g. “In QA” or “Needs Acceptance”), how to better document your work, etc. Make sure that you have a plan for implementing  at least one or two ideas from each retrospective and reflect on whether your most recent changes were effective.

Before you know it you should be talking about how to take the next steps to becoming more Agile. Perhaps you’ll want to establish a true development iteration. Maybe you’ll want to start estimating your work for planning purposes. Maybe you’ll want to select an unofficial Scrum Master or Product Owner for the team. Whatever you do, keep improving!


Documenting your work on a whiteboard, holding daily stand-up meetings, and retrospecting on your development process are three easy ways to start getting Agile. If you can implement these then you’ll start prioritizing more effectively, communicating more frequently, and you’ll ensure there is a guaranteed mechanism for improvement.

Have more questions about getting started with Agile? I’ve been through the bottom up approach and would be happy to discuss your own unique challenges if you need help getting started. Good luck.

Software Developer – Not Just Another Rung in the Corporate Ladder

I often see Software Developers (aka Developers aka Software Engineers aka Programmers, etc.) concerned with the long term prospects of remaining “just” a Developer. Although they may have an aptitude for software development, they fear that unless they get promoted out of a development role then their career will grow stagnant. To make matters worse, companies may even “promote” good developers to other positions — like a Business Analyst or Project Manager — which may be regarded as higher up the food chain. I contend that being a Developer is a career path of its own, and any “promotion” out of that role is probably just be a lateral move into a different profession.

Having filled the role of Developer, Business/Systems Analyst, Project Manager, and Development Manager, I can say with confidence that a great Developer can often times contribute to a software project in a bigger way than these other roles. In an Agile environment, a Developer is empowered not only through doing the actual development, but by helping with requirements, providing estimates, bringing new ideas to the table, testing, etc. On the other hand, a Business Analyst, Project Manager, or Development Manager most likely cannot directly contribute to the actual software development — which is of course the most fundamental thing that has to happen for software to get built. My point is that a Developer ultimately makes the most important contribution in a software development project, and may even have the most challenging job.

A second point is that good Developers scale in value much more quickly and for a much longer duration than most other professions. That is, a Developer with two years of experience might be twice as valuable as they were in their first year. A Developer with five years of experience might even be five times as valuable as they were in their first year. You can probably think of your own experiences where one experienced Developer was an order of magnitude more productive than a junior Developer. Many professions hit a plateau relatively quickly and do not see this kind of growth in value. So long as your contribution to work is growing year after year then you should expect to see your income growing year after year. In these other kinds of professions where your value plateaus quickly, you could understand why one might want to get promoted out of their role. The point is that Developers are valuable, and exceptionally good developers are exceptionally valuable. If you are passionate about development then you could reasonably expect to stay within the software development profession and make a good living.

That being said, these other roles can be equally impactful and can be extremely rewarding as well. If you are passionate about something other than development, or you believe you can make a better contribution as a Business Analyst/Project Manager/Development Manager/Team Lead/etc. then go ahead make the career change (but notice I didn’t call it a promotion).

Does the career path of a Developer scale at your company?

What Does a Development Manager Do?

As a (software) Development Manager myself, I am always pondering exactly what it is that makes someone great at this role. While surely every company has their own take on the role (if they even have the role!), here are my thoughts about what makes a good Development Manager.

As with other members of the development team, the primary responsibility of a Development Manager is delivering software. Obviously this needs to be the right product, with the appropriate level of quality, delivered in an acceptable amount of time. Without directly gathering requirements, doing design work, developing, testing, etc., how does a Development Manager contribute to delivering great software?

Here are what I believe to be the most important responsibilities of a Development Manager that have a direct impact on a team’s ability to deliver effectively:

  1. Ensure your teams are following an effective development process. This should likely include a focus on communication both within and outside the development team(s), a continuous improvement model like frequent “retrospectives”, and some basic mechanism for measuring and communicating progress. This is in large part what being Agile is all about. A hugely important function of a Development Manager could also be drumming up support for Agile if there is a culture challenge within your company.
  2. Do the normal managery stuff. Make sure teams are appropriately staffed and equipped. Mentor the team leads. Train and grow team members. Make sure people are happy. Be accessible. Break down barriers for your teams. Keep your teams informed of what is going on in the business. Participate in the budgeting process. Share responsibility for failures and shield your teams from politics and drama.
  3. Keep upper management informed. Upper management should know what your teams are about. Let them know about your teams’ successes and opportunities on a regular basis. The only way you can grow your teams and get the resources you need is if the company understands and believes in what you are doing. This responsibility would ideally be shared with the Product Owner(s).
  4. Understand the business and advocate technology solutions. As with a Product Owner, I believe a good Development Manager needs to have command of the company’s strategy and major initiatives. This understanding coupled with a strong grasp of technology and your teams’ capabilities puts the Development Manager in an excellent position to advocate solutions which can be delivered by your teams. Of equal importance can be understanding what is not a good fit for your teams. For example, don’t commit to building an enterprise chat system when there are perfectly good packages that could be purchased instead.
  5. Help wherever it is needed. A Development Manager needs to have a strong technical background and needs to understand all of the roles of the cross functional team. I believe a good Development Manager should be able step up and provide hands on help when the team really needs it. This could be anything from doing actual development to manual system testing to requirements refinement and gathering, or anything else that might be blocking the team. If this is happening frequently then it is a sign of a bigger problem, but occasional help at this level is appropriate.

What do you think are the most important functions of an effective Development Manager?