Do i really need a Daily Standup?

Sendhil shared this presentation “Observations from an old warhorse” by Fred George recently. I found an interesting topic he discusses in this talk, The Daily stand up meetings. A Must watch Video.

The purpose of the Daily stand up meeting is to facilitate the feedback cycle, promote communication and help in re-planning.

Scrum suggests that there are three things which gets discussed in a Standup meeting 

  1. What was accomplished yesterday,
  2. What will be attempted today, and
  3. What problems are causing delays

Fred George talks about what is more important to look at in the Standup meeting.

The most important thing for the person facilitating the development is to attend to When someone says “No Updates” or “Couldn’t get anything done yesterday“.

These are the people who are stuck because of
Exhausted

  • A complex problem,
  • Story was too vague,
  • Bleeding edge technology,
  • Gone into a tangent with design,
  • A/C was too cold,
  • tube light was not at the right place,
  • or for whatever is the reason.

Check this link for a sample list of impediments

These are impediments and it has to be addressed immediately so that people can move forward and meet their commitments made on a daily basis.

Another place to look at is the Individual Burn chart. If the hours are not reducing then it means that people are stuck and attention is required.

Team LeadDuring the Standup  Open the Plan or Stand next your Scrum Board/Kanban Board while discussing, mention the story so that everyone has the context.

If the meeting is used for the right reason, for sure it improves the communication and gives effective feedback.

Don’t spend too much time on people who could get things done yesterday. Listen carefully when people say i couldn’t get things done yesterday. Addressing their impediments will help them move forward and can get the results.

Happy Learning!!!

Image courtesy
Ambro / FreeDigitalPhotos.net
digitalart / FreeDigitalPhotos.net

Lean Startup : Useful Pointers to get started

I started reading the book “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses” about an year back. For sure, it is an impressive thought process. From that time on wards, I have been reading, discussing, practicing ( some form), Selling Lean Start up ideas 🙂

The Lean Startup is a business approach coined by Eric Ries that aims to change the way that companies are built and new products are launched. he Lean Startup relies on validated learning, scientific experimentation, and iterative product releases to shorten product development cycles, measure progress, and gain valuable customer feedback. In this way, companies, especially startups, can design their products or services to meet the demands of their customer base without requiring large amounts of initial funding or expensive product launches.

Via : http://en.wikipedia.org/wiki/Lean_Startup

I found an interesting place where you can test your knowledge on lean start up.
http://www.veri.com/t/lean-startup/18
I scored 195 points 🙂

If you are new to the concept of lean start up, here is a list of useful pointers which can help you get started

Lean Startup – Book Summary

Principles of Lean Startups

Lean Startup: How to Learn fast about Customers, their Problems and Solutions

How to Lean Startup? A Flowchart

Using Lean Startup Principles

Lean Startup Cycle

Customer Development Engineering

Combining agile development with customer development

How Development looks different in a lean startup

Lean Startup (PHP World)

Implementing Minimum Viable Changes as Part of a Lean Startup for change approach

Iterative funding of start ups- an entrepreneur’s perspective (Check the Image)

Contrasts between Agile and Lean Startup

Continuous Value Delivery

Happy Learning!!!

Zen and Unit Testing : Write Tests or become a Manager

Myself and Sendhil used to run Agile Software Development course during our Proteans days. As part of our course, we used to use The way of Testivus to talk about the importance of automated unit testing (POUT/TDD).

I happened to see the presentation couple of days back and felt very good. Thought i will blog about it.

IF YOU WRITE CODE, WRITE TESTS

The pupil asked the master programmer:
“When can I stop writing tests?”
The master answered:
“When you stop writing code.”

The pupil asked:
“When do I stop writing code?”
The master answered:
“When you become a manager.”

The pupil trembled and asked:
“When do I become a manager?”
The master answered:
“When you stop writing tests.”

The pupil rushed to write some tests. He left skid marks.

If the code deserves to be written, it deserves to have tests.

GOOD TESTS FAIL

The pupil went to the master programmer and said:
“All my tests pass all the time. Don’t I deserve a raise?”

The master slapped the pupil and replied:
“If all your tests pass, all the time, you need to write better tests.”

With a red cheek, the pupil went to HR to complain. But that’s another story.

Original Link: The Way of Testivus

Effective Test Case Automation using Robot

Couple of weeks back, a friend of mine asked me a favor to help him create/choose an automation framework for his teams. Me being at home most of the time now, it sounded like an interesting stuff to look at.

Though i am always inclined to create a DSL for automation, my previous experience with creating automation framework reminded me that it’s not something which you can do tomorrow and need a reasonably good budget.

I started looking for options and i landed up with this amazing open source framework called Robot. I evaluated it against our selection criteria and it pretty much fitted the bill. Ofcourse, no framework can give you everything you need, but as long as there is an option to extend i am sure it will do the needful.

It took a day for a fresher/junior resource to get started and in a weeks time, the test cases have actually started coming. More than that, they were in the format which is readable by product owners, business analysts and test engineers :). If you have written code in any of the existing frameworks using a programming language, i am sure you know the fact that however you have made your code readable, non-techies will always find it very difficult to read them.

Useful resources on Robot, which can help you get started

Robot Framework Tutorial Overview
Writing Maintainable Automated Acceptance Tests
How to write good test cases

Happy Learning!!!

Experience working with an ‘a’gile xp team

People are more important than any process. Good people with a good process will outperform good people with no process every time. — Grady Booch

Its been more than 7 years since i have worked with a team practicing XP. I recently started consulting with a startup firm where they are practicing xp and its definitely a very different experience. Thought i will summarize some of the very good things i am seeing in the last few weeks.

Hiring: People who have worked with me know the way my teams used to hire. Our interviews used to take 3 to 4 hours at the maximum. Now i am seeing people having interviews for a total duration 7 to 8 hours (Law of attraction!!!!)

Generalists : One of things i have always struggled is to sell the idea of generalists. People always wants to work in specific things which make them specialists. I am seeing for the first time in a services company that some one has even thought of promoting the concept of generalists.

Pair Programming: First time in my career i am seeing people practicing pair programming religiously. Its a very difficult proposition to do it from a small services firm and i guess these guys haven’t compromised on the quality aspect.

TDD, ATDD : Though, i had sold these very agressively, sure its very difficult to implement them. Very happy to see people write tests 🙂

Am forced to refresh my agile knowledge after i started consulting these guys.

Happy to start practicing ‘a’gile again 🙂

Automation Landscape

Have you ever thought of how the automation landscape looks today? More and more we develop applications on an iterative fashion, the more we realize the importance of automation.

Automation is no longer a tester’s work. If you are a developer i am sure you would have worked in automating either one of this (Build, deployment, test, performance, load) at some point of time in your career.

Today Mobile has become main stream. # of devices, platforms has increased. Its no more just web.

I just thought of summarizing the automation landscape. Obviously, i cannot add every other tool/platform exist in the world. Just added the ones which i have used/sold at some point.

I am sure it’s probably going to get even bigger. If you are a developer, who has not used any of this… then better get started learning these.
Automation Landscape

Related Posts
Thoughts on Automation as a Career : Role, Responsibilities and Career Progression
Iterative Development, Manual Testing and Frustrations

Happy Learning!!!

Architecture: How much is enough?

New product development is complex. One of the challenges I always see with development teams embarking in new product development is with the decision on how much architecture is enough.

I am sure we all have crossed the stage of BIG DESIGN UP FRONT (BDUF). It doesn’t work with changing requirements and I am sure all the software development effort we have today has changing requirements.

Industry has evolved over a period of time and has come up with an answer called YAGNI (YOU AIN’T GONNA NEED IT). Objective of this is that unless you need something, don’t build it.

Ok, what is the big deal on this?
ArchitectureLet us say you are building a house. Your foundation will form the structure for your building. If your foundation doesn’t support a certain design, there is no way you can build your house with the design. Meaning, it is very difficult to reshape the building once the foundation is done.

What is the solution for this?
There is no silver bullet. Balance is very important to anything one does, which I call as Minimal architecture definition.I see, people struggling with the definition of minimal architecture.

What defines a minimal architecture?
Minimal Architecture is not about your Visio diagrams or the colourful dubbas (boxes) in a PowerPoint presentation which can be checked in to your source control and helps you clear CMM or ISO Audit.

Minimal Architecture is something that,

  • Gets you started with your development
  • Enables development with minimal rework. One way to evaluate is the cost of rework during your development. I am talking about rework and not refactoring. I have seen many people calling the rework as refactoring (So that no one bothers to ask why there is rework).
  • Can evolve. Requirements will evolve over a period time, so does the architecture and design.
  • Is Testable. A Common question I see with stakeholders is that will this work? Human nature is that it will be very hard to believe anything until seen. Is there a way the architecture/design can be tested against the business goals so that it gives confidence to the stakeholders? Till it happens, architecture is a set of boxes aligned in a certain way J
  • Can scale. When I talk to product teams about scaling, the immediate answer I get is we do not know the requirement. True, you may not know the exact requirement as it is a new product. But you should be having some rough idea on the target market. Can your architecture address your current market and can scale if there is a future need. As I mentioned earlier, the structure of the house will be dependent on the foundation. If this is not done, there is no way you can say whether your architecture can meet your business needs.

Obviously, there can be more. In my opinion you will have a decent bet on the architecture if the above are answered and obviously you can scale. A little effort in planning can help you do much better during the development.

One of the things which I learnt is, all these has to be reviewed on a regular basis and it requires participation not just from the team, but also from all the key stakeholders.

Can this guarantee Success? May be/May not be. At least you will have a decent idea about your project and whether it can succeed. It can at least guarantee you that, you don’t have to bring in a consultant towards the mid/end of project to review your architecture.

Reference:
Lean Architecture for Agile Software Development

Happy Learning!!!