I “Post Master”

Delegation, A topic which cannot be missed in any management books. The message is don’t try to do everything by yourself. By delegating to others (who is capable of doing), you can groom the person, help him to grow and one can focus on the most important tasks.

But, what is the key here?

• Don’t do everything by yourself… It doesn’t say don’t do anything at all…
• Delegate to a person who is capable. “Horses for courses“
• Follow up in a regular interval, check if things are going OK and whether the other person needs any help.

Check here for the 12 Rules for delegation

But People are different. They take only what is important for them. Anything and everything can be delegated to others…

I recently spoke to someone (Let us call him A) who took over an account from another manager. This account is a crucial account and there is a struggle to fill the key position for this crucial account for a very long time. There was no progress made for about 7 months till A took over and suddenly in the last 1 month, there is enough progress that has been made, which is visible.

How come someone couldn’t do anything for 7 months and there is a sudden change in the last month? You can say “Luck“… But that’s not the truth. The Previous person delegated his work to someone and probably that someone delegated it to someone else and this chain could have extended further down and no one had any accountability.

But, since its a crucial thing, A has personally started working on it and because of that things have started moving, and the progress is visible.

Did A do anything different in this context? No, A just did his work and nothing else…

Delegation is important. Delegate when your plate is full, or you know someone else is ready and he can do the job so that you can do something more important.

Don’t Delegate because you have a person and you don’t want do anything at all…

If you do so then you can proudly call yourself as “I am a Post Master….”

Happy Learning!!!

Image courtesy

Ambro / FreeDigitalPhotos.net
Dundee Photographics / FreeDigitalPhotos.net

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

• 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.

During 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

Release Planning and Schedule Monitoring : Myth or Real

In the previous post, we looked at the issues with estimation and for sure it’s clear that there is no way one can estimate accurately.

If you want to plan and monitor a release, the first thing one should know is the pace in which his/her team is running and the second is where we stand as of now. All the management care is if you cannot complete it tomorrow, when you can complete.

Obviously, one cannot go to their senior management and say it will be done whenever it is done. I am sure, we all need our jobs .

But is that an excuse for the manager’s to sit idle and do nothing saying my developers are not giving any estimates or say I have got you an extension whenever you asked for. For sure, most of the managers rely on their techies to give the real picture. But isn’t that we all have some brain and we should put our brains to some use?

In one of my previous posts i have talked about my view points on this “Are we there yet?”

There are two things one as a manager can implement, which can help him make informed decisions.

CYCLE TIME

As a manager one of the tools that can come handy for monitoring is the cycle time. Cycle time is the time that takes to complete a feature/story/task from start to end. Now classify your stories/features/tasks/whatever you have, in the format of small, medium, large, and extra-large.

Calculate the cycle time. What one should be more interested is on the Average. Display your average time takes to complete the Features on a White Board. Build a Trend chart on the same so that everyone knows how things have changed (whether you are spending more time or less time) over the course of the development.

What if we realize that we are taking a lot of time to complete a feature?

There are two things one can look at.

• How much time is spent at each section (Analysis / Development / Acceptance)
• The Lead time to move a story from one section to another

This will give you the complete insight and all possible optimizations can happen after that. This will not only expose the problem within engineering team, but also the time spent in requirements. Say for example: If you see your team members spending most of the time in Analysis, i am sure you know where to optimize.

What are the benefits of doing this?

• As a manager, one is not only dependent on the team to get the estimates. 95% of the teams are into brown field development and this will help big time.
• Everyone in the team knows how much time approximately it takes to get anything done (since the average time and the trend chart has been displayed). If you are the Product owner, it’s easy to plan for releases by seeing the average time taken and the trend (whether it’s taking more time or less time).  Will it still be accurate? May be or may not be. But then you have some way to predict (using the Velocity Chart, Cycle Time and Cycle Trend) rather than just shooting at the dark.
• Oh, this works for Brown field. But ours is Green field. Sure, you cannot change the estimates given. But even in your Green field you still need to plan for releases and this will be very helpful even in that case.

What are the downsides of it?

• Project status will be crystal clear for all the stakeholders. People can make informed decisions.

VELOCITY CHART

Check this post from Johanna on creating project dashboards to display progress

Create the Line chart with Markers in Excel sheet which displays

• Total Number of Features to be delivered in the duration of the project in X Axis and
• Duration of the project (Week wise or month wise) in the Y Axis

(A Velocity chart for one of the projects i managed in 2009. This Snapshot was taken sometime around 26-Jul-09)

This will help you see the Features done on a week wise or month wise and the features left on a weekly or monthly basis. If there is a new feature or a set of features added on a specific period it will also show you a spike of the remaining features and anyone with common sense can understand what is going on in the project. If you need the project to be done on time, then most likely the Features done line and Features Remaining line has to meet in the middle.

What are the benefits of doing this?

1. First, it gives a clear status on what is going in the project, how many features done, how many left and how many are newly added etc.
2. Second, it helps the manager in clearly showcasing the changes that happens in the project. So no need to defend saying features added or modified is troubling the guestimate. In other words it helps in CYA…
3. Third, the manager do not have to go to a techie to ask where they stand if he/she has to give a monthly update to the stakeholders.

What are the downsides of it?

1. Project status will be crystal clear for all the stakeholders.
2. Manager has to work. Apart from giving GYAN to the team members saying they need to be disciplined with their code, Manager also has to be disciplined in creating, updating and maintaining this which is quite some work. Of course, one can always find an executive assistant to do this. J
3. Manager cannot blame someone else when things go wrong.

This sounds good. But how will it help me solve my estimation problem?

One may not get rid of the issue with estimates completely. But if this data is captured organization wide and have some way to classify data, you still have some scientific way to estimate rather than guesstimate  Of course, I do understand that every project is unique and the complexity varies.

An almost immediate thing which you can expect is

• Oh, we don’t have such tools in our organization or project.  You don’t need a tool to do all this. You can do it using Excel sheet. Immediate response would be i don’t know how to create a line chart in Excel. All you have to do is type “Line charts in Excel” in Google and click “I am feeling lucky”. Of course one needs to read it which is beyond the scope of this post
• The other thing is oh, we are not agile. For sure, you don’t need to be agile to do this. Anyways most of us who claim that we do agile do not anything about agile.

IMHO, it is all about bringing in some discipline within the environment, and with a very minimal change everyone can gain.

Happy Learning!!!!

Image courtesy

ddpavumba / FreeDigitalPhotos.net

The Estimation Myth

My discussion with Sendhil on this topic started after reading the recent blog post from Ron Jeffries on Estimation is Evil.

I had a wonderful opportunity to listen to Linda Rising (Author of the book: Fearless Change: Patterns for Introducing New Ideas) at the Agile India 2013 Conference recently on this topic Deception and Estimation – How we fool ourselves.

If you are a Manager or a developer or a Tester or Director or you do anything related to Software, listen to this talk. To me, Linda is one of the masters of storytelling. Watch this video and you will understand.

My version of the example on this: 

Have you ever been to a local salon/barber shop on a Sunday?

In India, we don’t have the concept of taking appointments yet with local salons and the salon will be crowded with people. If you enter the shop say @ 10 AM, you will see at least 5 guys waiting and at the max the local shop will have 3 people working. Now the shop owner or the leader of this 3 will look at you and say 10 to 15 minutes sir.

You know for sure there are only 3 guys working and there are 5 people waiting to either get a haircut or shave or head massage etc… How in the world they will be able to finish the 5 + 3 in 15 minutes and attend you? If you are a logical person, who wants to leave they will still persuade you saying wait sir… it will be over very quickly and you most probably end up listening to this and spend few hours of your Sunday in his shop.

What does it communicates to us?

• First of all we don’t have any clue on how much time it will take to complete a specific task (even with the guy who is doing the same thing his whole life) – > (Developer, tester)
• Second, we as humans always want to communicate to the other person in the way he feels comfortable  -> (Manager)
• Third, we as humans are always optimistic (even when we know that things cannot be achieved in a specific time) – > (Client)

Linda in her talk refers to a research where in as humans

• If speak for ten minutes there will be 3 lies at least in that.
• We are tuned to say and accept lies right from childhood. Example she quotes is that a Grandparent gives a gift to their grandchildren. Even though the child, doesn’t like it, as a parent one excepts their child to say “It’s a very nice gift and that’s exactly what they were looking for”

So how does it translate to our software projects?

• If you are developing software for whatever period, there is no way you will be able to provide an accurate estimate.

• If you are a Manager, even when you know that you will not be able to meet the commitment, you will still persuade your client saying that you will be on time.

• If you are a Client listening to your vendor or to your own team, even when you know that it will not be done on time, you will still accept saying that it will be done on time.

In his book “The Mythical Man Month”, Frederick Brook mentions all Programmers are optimists. The underlying assumption of scheduling is that “all will go well”, i.e., that each task will take only as long as it “ought” to take. It’s a book (bible) for everyone who is into software business.

So much has been said / discussed about this topic. But even 30 years after Frederick Brook has written the first version of his book, nothing has changed. We still believe in the same model.

The other side of the equation is that if I don’t know the numbers I will not know how much I need to spend and when I can go to market. How will I get bid for a RFP? How will I give a number to my CEO so that he approves the budget?

As a Manager, it is very clear that one need to still give estimates as the Top Management/Middle Management with whom you are dealing with doesn’t understand this and they need an estimate. So as a manager, one do not have an option, other than giving their gut feel numbers.

But is there anything that can be done which can help us and in turn we help the senior management and top management to make some informed decisions?

Let us see it in the next post…

Happy Learning!!!!

Image courtesy

nuchylee/ FreeDigitalPhotos.net

Arztsamui / FreeDigitalPhotos.net

The immortals of Meluha

Last week Seema and Jawad talked very high of this Novel “The Immortals of Meluha“. I don’t have the habit of reading Novels very regularly. I inquired more about the Novel and they were surprised that i didn’t know about “The Shiva Trilogy”.

The Shiva Trilogy is a three part Novel and the third part is due this month. There was a very good deal in Homeshop18. I immediately  ordered the combo (1st and 2nd Part) and to my surprise got it delivered in 2 days.

I started reading the Novel yesterday and couldn’t put it down. I finished it in two sittings.

There is only one word i can use to explain the feeling. “Awesome“… Its been more than 2 years since i have read a complete novel or book (First to last page) in one single day.

Om Namah Shivaya!!!

My special thanks for Seema and Jawad for recommending this book to me.

Happy Reading!!!

How Long Does It Take To Build A Native Mobile App?

Found an interesting info graphic on How Long Does It Take To Build A Native Mobile App?

From the Post

In a survey of 100 native mobile developers, Kinvey determined that creating a fully functional and polished app takes a team about 18 weeks from start to finish. That includes both front-end design and user interface as well as back-end integration like push notifications, user management and authentication, caching and sharing through social channels.

I know what many app developers are thinking when they hear that: “18 weeks?! Who the hell are these turtle-slow developers?” On the other hand, enterprise developers are probably saying: “18 weeks?! We are only halfway through by that point.”

Original Link here

Good One.

ASP.NET Web API Vs WCF? What should i use for my project?

Microsoft defines ASP.NET Web APIs as

a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices.

ASP.NET Web API is an ideal platform for building Restful applications on the .NET Framework.

But wait… We do have WCF as part of .NET. So what is this Web API all about? When should I use this?

I was looking for some guidance to use during the solution process, but couldn’t find much help. After a bit of struggle, landed up in this web page which talks about features and when to use in detail.

From Microsoft Site

WCF	ASP.NET Web API
Enables building services that support multiple transport protocols (HTTP, TCP, UDP, and custom transports) and allows switching between them.	HTTP only. First-class programming model for HTTP. More suitable for access from various browsers, mobile devices etc. enabling wide reach.
Enables building services that support multiple encodings (Text, MTOM, and Binary) of the same message type and allows switching between them.	Enables building Web APIs that support wide variety of media types including XML, JSON etc.
Supports building services with WS-* standards like Reliable Messaging, Transactions, Message Security.	Uses basic protocol and formats such as HTTP, WebSockets, SSL, JQuery, JSON, and XML. There is no support for higher level protocols such as Reliable Messaging or Transactions.
Supports Request-Reply, One Way, and Duplex message exchange patterns.	HTTP is request/response but additional patterns can be supported through SignalR and WebSockets integration.
WCF SOAP services can be described in WSDL allowing automated tools to generate client proxies even for services with complex schemas.	There is a variety of ways to describe a Web API ranging from auto-generated HTML help page describing snippets to structured metadata for OData integrated APIs.
Ships with the .NET framework.	Ships with .NET framework but is open-source and is also available out-of-band as independent download.

In Summary

• Use WCF to create reliable, secure web services that accessible over a variety of transports.  If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.

• Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services.  Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API.

Couple of Must Read blog entries on this topic
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec

http://idesign.net/articles/asp_net_web_api_vs_wcf.htm

Happy Learning!!!