Tuesday, November 8, 2011
Tuesday, November 1, 2011
- Be SOLID - Learn the S.O.L.I.D. principles. Practice them. Take no prisoners.
- Get DI - make sure that you and everyone on your team REALLY gets Dependency Injection and uses it where appropriate. If you do it right, you'll thank me later. If you don't you'll probably curse me. If you find yourself cursing me, re-read that.
- List, List, List - Really, really, really know the product backlog. Know where the Product Owner wants to take the product. Get behind that. Give the team whatever they need to succeed and then get out of the way
- Be debt free - Perform an HONEST Technical Debt assessment. Identify it, put together a plan to either abandon it, call it legacy (thereby putting in a plan to abandon it), or fix it. Before doing anything else, do something to prevent it from happening again. The best thing to do is the next item.
- Invest in the team - People are your your greatest asset. Treat them fairly, hold them accountable, expect them to hold each other accountable. The best, and most important way to do this is to foster a safe haven environment, implement code reviews as a means of avoiding technical debt as well as a learning tool. Discourage/punish anyone/anything that violates the safe haven.
- Get TDD - If your standard development practice does not include unit testing [which dovetails nicely with the SOLID principles], you're missing out on the opportunity to take advantage of the benefits provided by the Single Responsibility Principle or the Liskov Substitution Principle. The idea is pretty simple, write the code once and then test it every time something changes.
- Get CI - If you already have a Continuous Integration environment, props to you. If you don't and are writing unit tests, don't walk but rather run to get a jenkins or some other CI solution running. Chances are if you've embraced TDD and don't have a CI solution, you're leaving most of the value of TDD on the table.
- Bigger is better - Make an honest assessment of the team's communications. Look at the tools, protocols, frequency,etc. This is especially important for teams that are not colocated. If your team is relying on any type of asynchronous communication (email, IM, twitter, LCS, etc.) you're penalizing yourself. Preferred modes of communication: 1) face to face 2) telephone or Skype 3) Instant messenger or twitter 4) Email 5) Snail Mail.
- Embrace Legalism - Follow Scrum by the book for a while in order to figure out where it doesn't work. When you find something that doesn't work for you, try it again the original way, and if that still doesn't work, keep trying until you are absolutely sure that there is no alternative. If you change something, consider yourself warned.
- Evangelize - Put forward a concerted effort to gain product owner investment. If the person you identify as the Product Owner wants to delegate the responsibility, you have a sales job to do and will likely require some convincing to the "real" PO (not a proxy PO) in order to to take away the cya/escape hatch (aka finger pointing/plausible deniability) that business people are so accustomed to when dealing with software projects.
- Be a mechanic - Inspect and adapt the technical/engineering practices in order to continue leveraging value. Think outside of the box and try new ways of investing in the skills of the team. For example, if you've never done it, try pair-programming for a couple of sprints to see if it helps or hinders the team's performance.
I've been thinking about how to help a colleague get his arms around a Scrum implementation that seems to be out of control and rife with what my friend Ken Schwaber refers to as "ScrumButs". During our conversation, I cringed several times when reference was made to their "version" of Scrum as well as their version of "TDD". Yikes. I think that this is a common trap that managers fall into when trying to adapt their organizational culture to become more "Agile". The bottom line is that if you're adopting Scrum because of business value motivators like profitability, product turn rates, cost control, or to compress/reduce feature release windows then I would tell you that your heart is in the wrong place and that you really need to re-assess what the value proposition is for implementing Agile software development methodologies/techniques. In my opinion, being successful at Scrum requires more of a change in personal and managerial philosophy than it does any type of technical or procedural change. You see, I really struggle when I use the term "methodology" in the same sentence as Scrum because it's not really a methodology...nor is it a technique....framework...technique...bleh. It's all of those and none of them at the same time. Scrum is a philosophy. It's a world-view relating to managerial interaction with those involved in production. If you want to know how to succeed at implementing Scrum, I would recommend that you start with a read of Ken Blanchard's book titled "The Servant Leader". Once you have your heart in the right place, you've put aside the "command and control" mindset and embraced the TPS/Lean concepts of empowering and enabling your staff to make decisions, and resolved to give the power to make those decisions to the team, now you're really ready to tackle the hard stuff like finding, training,and getting on the same page as the Product Owner and starting down the Scrum road. Much like political or religious world-views, If you can't put aside, or your organization isn't structured to let you put aside these fundamental beliefs and opinions about people, roles, and responsibilities, you really need to abandon the idea of implementing Scrum/Lean/Agile until you can come to terms with what it means to lead people versus what it means to manage them.