, ,

New to Agile?

In short, agile and lean are general concepts, the former basing on Agile Manifesto and the latter on Toyota Production System. Then we have Scrum or XP, built over agile, and Kanban, built over lean, which are specific methods teams can implement, like Prince2.

Personally, I don’t treat agile and lean movements in a very orthodox way — they base on the same principles. So, to some point, they’re overlapping. Also, you will find teams mixing methods from both houses, Scrumban (a combination of Scrum and Kanban) being probably the most common.

If you wanted to position agile/lean methods somehow I’d say that:

  • Scrum is the closest to the old-school project management methods, although it doesn’t really deal with formal side of project management.
  • XP focuses on engineering practices and is generally programmer-centered.
  • Kanban is often dubbed change management framework as it doesn’t change the way team works on the day 1 and lets the process evolve over time.
  • As all three focuses on different things, it isn’t uncommon to see them, or their parts, used jointly.

If you want to learn more I’d start with such set of materials:

  • Introduction to Scrum on Mike Cohn’s site. If you want more on Scrum Mike Cohn’s site is a good place to find also more advanced stuff on Scrum.
  • Once you know what Scrum is I’d strongly recommend Henrik Kniberg’s and Mattias Skarin’s minibook Kanban and Scrum – Making most of both which is great in terms of describing Kanban but has a lot of referrals to Scrum.
  • For more advanced stuff on Kanban I’d recommend Limited WIP Society articles (topic for my next blog).
  • Good kick start on XP can be found on Ron Jeffries’ site.

In terms of books as a kick start, I’d recommend:

  • Mike Cohn’s Succeeding with Agile for Scrum
  • Kent Beck’s Extreme Programming Explained for XP
  • David Anderson’s Kanban for Kanban

If it is too much of a hassle to read these books and digest then contact us and we may be able to help you.

, , ,

Agile Learning and Seeking Knowledge

India’s Mars Mission

2013-11-05 09.23.07

A proud moment for every Indian as rocket lifts off from Shriharikota (South India). A massive step towards learning about red planet. This news prompted me to consider the current and future role of learning activities undertaken by people and organisations. Learning is acquisition of new information through practice or experience[1] and it occurs in response to a need or problem.

2013-10-25 18.55.17-1

During my MBA lesson at MBS Manchester, professor Norman Longworth describes the stages in human learning as “Information Ladder”. According to the ladder, a learner moves through the following progression to construct ‘wisdom’ at the highest level from ‘data’ at the lowest level:

Data -> Information -> Knowledge -> Understanding -> Insight -> Wisdom

Whereas the first two steps can be scientifically defined, the upper steps belong to the domain of psychology and philosophy.

According to Sherry L. Willis, a renowned researcher from US, long-term learning activities is the ability to acquire and retain relevant information and to solve problems. Problem solving involves assessing the present state, defining the desired state, and finding ways to transform the former to the latter. Decision-making refers to the evaluation of possible solutions and the selection of one for implementation[2].

A major difference between experts and novices is in their possession and use of two forms of knowledge: declarative and procedural knowledge. Declarative knowledge involves knowing what facts and information are relevant in solving a particular problem[3] .It is one’s knowledge of the subject matter. Experts have the ability to select quickly the most relevant information for a particular problem, obviating the need for a more exhaustive and time-consuming search through their declarative knowledge.

Procedural knowledge represents the individual or organization’s understanding of how to go about solving a particular problem—how declarative knowledge relevant in a particular situation can be combined to produce a solution[4]. Often the procedural knowledge involves performing a set of operations or following an algorithm.

Individuals and organizations that are new to Agile and Lean may spend much time developing or discovering a plan as they go about solving a problem. An agile expert is quick to develop an appropriate plan to use relevant information and solving a particular problem. The expert “plugs in” the relevant information to the plan or script which helps you to gain knowledge and apply with greater efficiency.

Please contact us and see how our experts can help you and your organization with learning Agile and Knowledge Management .

REFERENCES

  1. Howard and Howard, 1997
  2. Reese and Rodeheaver, 1985; Reitman, 1964
  3. Anderson, 1985; Chi, 1985
  4. Anderson, 1985; Chi, Feltovich, and Glaser, 1981
  5. Rogers, 2000
, ,

People arriving late to Standups/Scrum Meetings?

I have seen many Scrum Teams have trouble getting to their Standup on time, and being properly prepared. My suggestion is to get hold of some kind of “cheap simple noise device” (eg bell, hooter, drum, cymbals; NOT a mouth-contacting whistle/trumpet/vuvuzela).

Step 1: Make the warning noise of your choice 1-2 minutes before the meeting starts. (and maybe another 1 when the meeting actually starts!) Many team members, especially the usual latecomers, hate this approach, but it is highly effective. Especially when you try

Step 2: After 1-2 Sprints, select 1 person (somehow) who is still late/latest to the standups, and give them the power of making the warning blast – make sure the team knows who the week’s/sprint’s “victim/cop” is, and make sure they know just how vitally important their new responsibility is. You even get to take the device over to them at the right time, just to help them if they need further motivation.

Step 3: Usually after 2-3 Sprints, everyone is at least getting to Standups on time. If all is excellent, you may wean (or not) away from using the “noise device” – depends on whatever team culture has evolved in response.

Happy Scrumming!!!!

, , , ,

Refactoring

Recently overheard heated debate on code refactoring. I felt they were mixing up refactoring with rework and agile model was being blamed for not designing upfront therefore need for code refactoring. This resulted in waste of time, organically grown-poorly-commented-complex- code that needed retesting.

So, why and when do I refactor my code?

Simple answer is, when you are sure that you will never ever have to touch a piece of code again, there’s no need to re-factor that code.

But most of the time, you will have to touch it again because you will have to add features, fix bugs or optimize it.

  1. To eliminate/reduce the “Code Smells”
  2. Easier for any developer to understand the code
  3. To make it maintainable.
  4. To increase cohesion and to reduce coupling”

I don’t usually recommend refactoring just to reduce code smells, or make it ‘nicer’/more maintainable. I do suggest you refactor your code, when you need to fix bug, and you want to leave code in better shape than it was before. Other reason is when you want to add functionality, and it would be hard to do without refactoring. Third reason is to make code more testable. Sometimes refactoring will help you to learn the code which you don’t understand 🙂

Refactoring is used to pay your Technical Debt. Code refactoring is a necessity of observing the fact that change is inevitable. It’s principal goal is to enhance the current code or design in order to make it amenable and congruent with new functional or non-functional requirements or to make it more tolerant to change.

Examples of scenarios where refactoring may be necessary:

• Introduction of a new business rule that requires the current design to be abstracted to a new level;
• Recognition of the fact that the current design could be modified in order to better observe the SOLID principals of object-oriented design;
• When code testability needs to be increased—this relates to 2 above.

While you are refactoring
• Avoid code duplication when I see it (following DRY principle-need to write a blog on this too)
• Simplify the code (remove unnecessary ad-hoc complexities, KISS- keep it simple and stupid)
• Remove old/stale/deprecated code (cleaning waste, once the old code is replaced)
• Eliminate side effects
• Generalize and reuse existing code
• Reducing complexity of individual functions – makes testing easier
• Eliminating repeated code – reduces opportunities for mistakes

And finally, Its not waste of anybody’s time!!!!

, ,

Agile team and home working

Agile and home working seems to be at odds with each other. One is about close communication, co-location and short feedback loops; the other is about being effective with people working away from their usual office location. If terms like “Slow network”, “communication gap”, “different time zones”, “different work culture” sound familiar then you too are going through what I am going through these days.

The purpose of this discussion is to find out if a team can be agile while teams are distributed or few team members prefer to work from home. How do we create an effective and efficient team and still deliver quickly? What are the guidelines around home working?

We do have a need for people to be in the office, and it isn’t always possible. There are certain advantages and disadvantages of working away from the team.

Advantages:

Home working is mostly advantageous for the worker:

  • More Flexibility: This gives employees flexibility to sort out their personal work while at work. When working from home, your schedule at home is much easier to bend. It’s much easier to tie in your personal schedule with your work schedule when you work from home.
  • Less Transportation/commuting: This can help you get a little bit more sleep in the morning and have more time for yourself in the evening for activities & leisure. Arguably the biggest money saving benefit from working at home is the transportation cost savings.
  • Less stress & anxiety: An office can bring about a lot of competition, gossip, and backstabbing among co-workers. This type of environment takes its toll after a while both mentally and physically. Working from home will save you these headaches.
  • Increased productivity: With all the time that you are saving from not having to commute to work, and not socialising half the day with co-workers, you end up getting a lot more done when you are working from home. As long as you remain motivated and driven, working from home is much more effective to deliver results (provided there is no distraction from family members or pet).
  • Closer relationship: Working from home allows you to have such freedom and increase the chances of spending quality time with your loved ones which you just cannot put a price tag on.

Disadvantages:

  • Broken communication: Critical key to home working is the team member remaining in full contact with the team. This presents a number of difficulties with communication. Although you are only a phone call/email away, still direct discussion with team member can be more effective.
  • Reduced Productivity: My team had problems when a testing team member was based in South Africa. The internet connection was very slow (bandwidth issue) and it took ages to upload or download document (test script etc). The VPN connection timed out while testing software.  Other distractions can also reduce productivity.
  • Face2Face: When there is a need for people to be in the office for the key meetings, such as Sprint Planning, workshops, User Stories elaboration and estimation sessions where conversation can become many voices and fast paced. In this situation teleconferencing is least effective.
  • Emotionless: Working from home can restrict feeling of emotions other team members are going through, especially when system is going live or found a bug which needs immediate attention or just a taste of cup-cake baked by a team member to celebrate birthday.
  • Increased resolution time: It takes longer to resolve problems when a particular team member is required to resolve a problem or issue.
  • Loss of synergy: Nothing dynamic and thus you loose the synergy of two or more people working together seamlessly in a dynamic way, especially when team members are doing pair programming.

Tools to facilitate co-location while working from home:

To overcome these problems, there are certain tools available in the market to facilitate effective and efficient home working:

Tools like Skype, MS Communicator and Live Meeting. We have had people working from home in the UK and abroad. These three pieces of software mentioned above can help to alleviate this.

Mountaingoat’s online poker tool to be good for geographically dispersed teams though the session has to be very well planned for in advance.

Use SharePoint/web based document share (i.e. google doc) for document storage and of course any web based agile planning tool helps greatly across distributed scrum teams.

SMART Board: This is something I have started using few years ago. It is expensive to buy but comes with numerous benefits. The external invitee has a pen tray with colours, shapes and an eraser to interact with board dynamically plus we can hear them over the speakers – vice versa with a microphone of course. The software provides two way interactions. Plus we can use web cam too. Consider the situation where we have developers, testers and Product Owners geographically dispersed and you want to do something simple like interact with a script, do some design clarification or even show some interaction on the front-end before signing a User Story off.

Consideration needs to be given to the role of the person who home works. For example a Development Lead who works from home/off shore 2 days a week and this can present difficulties in having to take the role of Proxy Development Lead on quite a few occasions. This is really evident at go-live when they are off shore and the team are in the office. I agree that technology can not replace human touch but we all need to compromise somewhere or other. Therefore I recommend frequent face 2 face meetings, especially during team retrospectives or during point planning session and other activities which don’t need much of interaction with others can be performed remotely and make sure you are available online to interact with the team when needed.

Any other rules?