No programmers in Agile teams!

Yes, that’s right. Agile teams don’t need software programmers, they need software developers. I don’t mean this as some English vocabulary usage. I think the key difference is, if you ask a programmer to build some code, you will get code. If that programmer is good, you might get good, reasonably commented and reasonably efficient code which works.

If you ask a software developer to build some code, you will first get questions:) before you get a solution.

  • How does it fit in the business process? Are the requirements thought out?
  • Are you sure you understand what it will cost?
  • Who will support it? What about diagnostics and instrumentation?
  • What kind of documentation will it need?
  • How might it interact with other code?
  • What platform will it run on. Are the scalability issues?
  • How might it impact future development? How might it be enhanced in the future?

Another key difference is, programmers focus on languages, software developers focus on language characteristics. A programmer might see himself/herself as a Java programmer, C# programmer or a Ruby programmer. But a developer focuses on language characteristics such as strong or loosely typed? Object oriented or functional? Interpreted or compiled? Etc. This allows developers to quickly adapt and pick up new languages and technologies.

So, the key mantra for agile teams is to deliver high business value software with high quality. This cannot happen with programmers whose focus is just to code and ignore everything else.

Code is not always ‘THE’ solution but its ‘a’ solution.

Credit: This blog is inspired by a talk from Dan Appleman

Advertisements

You are fat..errr! you look big.

Back in collage days, I learnt a lesson when my friend almost killed me (not literally though 🙂 ) when I responded to a question by saying “yes, you look fat”.  Recently I noticed such a scenario in a team, well it’s nothing to do being fat 🙂 but fundamentally it was same, “Giving and taking feedback”.

I believe that feedback is a gift. It always helps us grow personally and professionally. Yet, most of us have a negative perception towards it. Most of us still believe age old saying “If you don’t have anything nice to say, don’t say anything at all.”

Today’s demanding and challenging work environment calls for an imbibed culture of giving and receiving feedback. This aspect should be even more emphasized in agile teams. For example, lot of agile practices have an inbuilt framework to facilitate faster feedback such as with XP, we have CI, Pair programming, Peer reviews etc, with scrum we have retrospectives etc. Most of these feedback mechanisms are targeted at technical accepts and abstracted at team level.

In order to have hyper-productive teams, individuals should be comfortable to give feedback at an individual contribution level to acknowledge his/her achievements or to identify any growth areas.

Here are some points on giving and receiving feedback.

  1. Give your feedback as soon as possible: If you notice something done really well, don’t wait till a retrospective or some event to give a pat on back. If it is appropriate, drop an email, or post it in a bulletin board about the good work. At the same time, if you see something can be improved, or done at substandard level, let the person know ASAP.
  2. Balance your feedback: Always start your feedbacks with a positive note. It is important to mix both positives and growth areas.
  3. Be Constructive: The whole idea of giving feedback to help the other person to grow and not to criticize. So, always give your feedback in a constructive way. Be careful with the language you use. Replace words such as “but” and “however” with the word “and” when you string together your positive and negative feedback. When people hear the word “but” they immediately discount the part that came before it and only hear the negative comments.
  4. Listen: While receiving feedback, listen to the other person’s point of view. Perceptions are true at least for the ones who own it. So here it out without any justification or explanation.
  5. Reaction: If you don’t completely accept the feedback, thank the person and tell him how you are going to take that feedback. Be careful, it sometime do happen, that rather than accepting the feedback, we tend to denounce not only what is said but also those who say it.

Always remember, if someone is giving you feedback, it means they are interested in what you are doing and wants to help you to become better at it. Now, coming back to my collage days, if I had known point 3, I would have said “This dress suites you very well and I guess you look little big now” (not sure if it would have really helped) 🙂

Should my Org/Team move to Agile?

Naturally, I’m tempted to answer “YES” to this question as I wear my Agile Coach hat at work. As I pay close attention to the person’s conversation, what he/she is really saying (screaming inside) is bunch of fears such as

  • Fear of failure
  • Fear of change
  • Fear of moving out of comfort zone
  • Fear of learning curve
  • Fear of wrong decision
  • Fear of transparency
  • Fear of losing control
  • And it’s so easy to give orders or follow orders J

So, when you want to convince your boss or your customer to go Agile, ask what challenges they think that exists currently with their organization or team. It’s much easier to focus on solutions and start that conversation when people acknowledge that a problem exists.

Just enough, just in time specifications

One of the best practices of Agile/Lean development is just enough, just in time specifications.  But this is often times misunderstood by teams and harder to align by business.

So what is a specification anyway? It’s a software feature required to meet the vision of the product. It talks about what but not how. It talks about the experience by customer rather than a database table or a technical framework.

Then, what is just enough, just in time specification? Well, let’s look at this case. If there is a steel manufacturing plant, how much raw material (inventory) should the plant hold? Should it be sufficient for next one year or for next few weeks? Of course it’s for few weeks, but with the expectation of continues supply of raw material. Before the raw material turns to steel, it goes through various stages, for heck of it, let’s say, when it’s in the earth’s ore, its 0.5% refined, after 1st treatment of the ore, its 25% refined and so on and so forth till it becomes a state when furnace can spit of the desired quality steel.

Even product backlog should be treated as inventory. It has ideas, concepts and specifications which are refined at various levels.

Image

Now, the problem is when PO comes up with a new requirement during planning meeting for the upcoming sprint, he/she and the team should be aware how refined the requirement is.  If you see all items directly end up in “Fine Grained” state, then you know it’s not evolving. This usually results in lot of readdressing existing which could have been easily avoided.

To sum it up, Just enough, just in time specifications should be part of an evolutionary process and will work of both team and business understands the level of granularity of the requirements.

Slicing Features – Part 1

I was part of “Slicing Features into playable stories” session by Tarang Baxi in Agile 2012. Case studies Tarang presented were very effective in emphasizing the principles behind Slicing features into stories. Let me try to put down two case studies which he discussed.

First one was about an ipad app to allow users (travelers of an airline) to complete check in online via their ipad’s. This app is intended to support users in 12 countries. Also, most of biz logic is shared with website and other mobile apps which mostly is already in place.

General outline of the requirement was something like this

  1. Initiate check in
    1. Ability to search  via last name,PNR
    2. Show a reminder letting user know that his flight is open for checkin (sort of check in notification)
    3. Login into account and use a dashboard page which displays booking  history (My Trips) and check in button next to it (both already in place)
  2. Check in info
    1. Passport info etc for international travel
    2. Each country has its own UI layout e.g. Japan has last name then first name
    3. Country specify information if any
  3. Extra / check in luggage
  4. Add ons
    1. On board meal
    2. Wifi
    3. Upgrades
  5. Payment for add on’s or luggage
  6. Seat selection
  7. Check in and send boarding pass based on user option/input Via email or To ipad

Now the question is what’s the best way to slice stories out of this feature (check in feature)? Product owner also mentioned that most revenue generating piece is obviously “Add ons”.

Principle: When slicing user stories, always ensure you get one thinnest slice end to end. In this case, first story team should focus on would be to get a base minimum flow to complete check in.  It could look something like.

UserStories

I’ll talk about next case study in my next blog.

Agile Transformation – Part 1 [How and Why Agile Check ]

Agile is the buzz word these days. Everyone is talking about it. Interestingly many organizations / teams think they are agile. As Pekka Abrahamsson says, Agile is a non defined term, so it seems to be everything or nothing. There is no line to say if you cross that you are opposite of agile. Agile or Agility is a positive term everybody wants to be associated with :) . Being Agile is a journey, not a goal.

This series of blogs will try to touch up on few aspects of agile transformation. Recently, I was talking to a team which said they can’t be Agile (or follow SCRUM) because they are working on legacy code and they can’t have good unit test coverage or builds on every check in etc. The team was under an impression that if they following a couple of XP practices they would be agile :) . This kind of misconception is equally true at management levels who perceive Agile / SCRUM to be a silver bullet to solve all of their problems.

Why to Transform

Organizations need to have a clear vision why they want to “Get Real Agile!”.  In my opinion, there are 2 key goals why an organization / team should go for an agile transformation.

  • Identify and effectively address challenges with their current base ground.
  • Increase efficiency/ effectiveness by changing organizational / team working structures to increase predictably, adaptability and happy peopleJ.

Common challenges I hear with traditional processes

  • Project timelines are missed.
  • Product quality concerns.
  • Project runs over budget.
  • Unsatisfied customers.

Agile Check:  Where do you stand now?

Agile transformation should be done iteratively. For this, we need a backlog of activities to deploy Agility / SCRUM into organizations.  This backlog is created (of course bound to change during deployment) during “Agile Check” with a cross section of the organization. Typically I conduct “Agile Check” with a group of 10 to 15 people which consists of managers, developers, QAs, team leads, architects etc.

Start Agile check with a stand upJ. Instead of a typical stand up, it’s about Name/Role, expectations from Agile check and anything they foresee going wrong during Agile check. This gives a fair idea of  mine as well as audience’s expectations.

Run a retrospective of their current process / structure. I like to give 6 post it notes to each individual, and ask them to write 3 positive points and challenges they currently face, one point on each sticky note.

Make groups of 3 to 4 people, don’t propose groups, instead, let me them arrive at it. Once they form groups, ask them to discuss among themselves and pick 3 positives and challenges at a group leave.

Each team presents their list then and a consolidated list of formed. Help them to arrive with top 5 positives and challenges from the consolidated list. I usually do it by voting. Each member gets 5 votes for positive and 5 for challenges. Each member can put his/her votes against the list based on what he/she feels important.

Now, we have a list of things that are working well and things to improve. Sometimes it requires some discussion around the same, but usually this is the time I give an introduction to SCRUM. Depending on the audience’s Agile exposure, this session’s focus ranges from explaining “Why Agile/Scrum” to core principles, and mapping them to retrospective list.

SCRUM Deployment backlog creation:

By now, groups would have understood what challenges they have, and how Agile/ SCRUM would help in addressing them. Ask teams to think about various activities which they feel are required to deploy SCRUM in their environment. Once every group has a list, help them to come up with a prioritized list. Usually I ask everyone what should be the first step. For e.g. someone would say, training is the first thing, someone might say, identify pilot project or management commitment. After this exercise, we end up having a prioritized backlog for SCRUM deployment.

That’s it, objective of Agile check is accomplished! A prioritized backlog for SCRUM deployment is ready.

Of course, once this is done, there is a management meeting when we identify and Agility Stakeholder, who owns this backlog and agree upon timelines, pilot project etc.

So this blog is about How and Why Agile Check. Stay tuned for more!