Stop singing when your voice is good; don't wait till it gets bad!

25 days ago | Biju Bhaskar: Thoughts on enterprise application development...

That is a saying in a local Indian language. It is more applicable for classical singing, where the quality of singers voice is very important. If you don't stop at the right time, all the name and fame you made by putting lot of hard work, might just fizzle away.

I had a similar advice to this high performing team mentioned in the previous post.  This is also applicable to many teams we see everyday, hence thought of sharing. It is about the art of figuring out when to stop.

This team has done all the hard work, made some high impact organizational and behavioral changes. Once they started to find it hard to make an impact on any particular workstream, or when they could not figure out what is next in a particular workstream, they could have closed that workstream. They could have celebrated all the achievements they made, and announced that they are closing those workstreams. That way all the hard work they did could have got the due credit and they can move on to new things. Because of not doing that, they opened themselves up to the critics who started questioning their impact based only on some recent developments.  I have seen this in many projects too... the projects we call " the ones with the long tail". So I would encourage you to think about "when to stop" whether you are in an initiative, or in a project, or even when you are in a job : )

By the way, I want to congratulate this team for all the great work they have done so far. They deserve all the credit ..

reactions?

Story of an high performing team...

about 1 month ago | Biju Bhaskar: Thoughts on enterprise application development...

I want to share a story of an high performing team..

This teams mandate was to take the organization to next level in agility. It had multiple workstreams and there were a pair leading each workstream. In the last few months, these teams had made major changes in the organization. Their impact was huge.

However, during recent weeks, couple of workstreams have been struggling to make an impact. They weren't sure how to take it to the next level in their particular workstream. In fact it came to a stage where they started to get negative press internally. Some were even questioning what they were doing... as the progress and value addition was not visible in recent times. What should they do at this stage?

I will write about my take in the next post...

Is IT about process or technology?

about 1 month ago | Biju Bhaskar: Thoughts on enterprise application development...

Neither...... it is the people that matters  : )

Neither Scrum, XP, Kanban etc going to build any great IT/app dev organization. Nor, J2EE, RubyonRails etc.. Always there will be new processes and technologies. But what matters most is the folks you have.

Are you hiring the right people? Are you taking care of your existing folks by focusing on their professional development, giving them growth opportunities, challenging work etc.? Are you understanding their personal goals and aspirations and supporting it? Are you creating an environment for everybody to grow? Are you creating an environment where folks can try new things without fear of failure? Are you managing out folks who are not doing well and are a burden on the team? If you are saying yes to all of these, then I think your organization is on the path to greatness. Then the folks will make the organization great...technology or process doesn't matter at all...

Agree or disagree?

Speaking at Agile NCR 2010

about 1 month ago | Biju Bhaskar: Thoughts on enterprise application development...

I will be speaking at Agile NCR 2010 this weekend. If you are in and around Delhi/Gurgaon region this looks like a great event to meet and hear from other agile enthusiasts.

 http://www.agileindia.org/agilencr2010


Here is the abstract of my talk:

Agile 2.0 - Our Road to Mastery
An experience report on how to sustain a successful agile adoption and take the road to mastery in agile.

Similar to other IT organizations we faced the challenge of keeping the momentum going after successfully rolling out agile. Some of the questions we faced were... how can we take the organization to next level in agile maturity? how can we make our good teams great? who should run it?

This report shares some successful change strategies, some failed approaches, and finally how we leveraged human passion to run the change process.

Where is Biju?

about 1 month ago | Biju Bhaskar: Thoughts on enterprise application development...

Apologies for not blogging for the last few months. It has been a crazy few months as I took up a new role in India. Now that things have settled down a bit, I plan to blog more. Keep watching this space  : )
thanks

"Next Generation Collaborative Enterprise"

7 months ago | Biju Bhaskar: Thoughts on enterprise application development...

There is more to leading a self-organizing team than buying pizza and getting out of the way....

7 months ago | Biju Bhaskar: Thoughts on enterprise application development...

 Leaders influence teams in subtle and indirect ways. Great post from Mike Cohn...

http://bit.ly/6iRRqh

Have seen many of our Scrum Masters/ leaders struggle achieving this subtle balance between command and influence Mike is talking about. This is a great skill to have.

Having said that, occasionally one will have to consciously let the team fail, as long as they learn from it and the impact is minimal.

Practice, practice, practice....learning this skill will take you a long way.

Engaging externally - Kudos to the team!

8 months ago | Biju Bhaskar: Thoughts on enterprise application development...

 2009 was a great year for us when it came to engaging with external world. We were more porous than previous years. It facilitated two way learning....as we learned from the external world, and external world learned from us. Great job team!

Some highlights....

- We hosted our own first Application Development conference
- Our folks presented at major industry conferences (like Agile 2009 and RailsConf)
- We continued to engage with great external coaches and other thoughtleaders in the industry (some on pro bono basis)
- Many of us have continued, or started blogging externally
- Our developers contributed code to opensource
- Our folks took lead in starting new meetup groups, and also contributed to many
- Outside firms (including non-profits) continued to reach out to us to learn about our agile transition success story

...and many more.

Considering that our budget situation did not allow our folks to attend any conferences, or bring in external experts in '09 .... that is an awesome start... miles to go though...

Happy New Year!

8 months ago | Biju Bhaskar: Thoughts on enterprise application development...

Happy new year everyone!

Dont forget to do your year end personal retro!

8 months ago | Biju Bhaskar: Thoughts on enterprise application development...

Its that time of the year again .... time for delivering year end evaluations. I am almost done with delivering evals,except for one. Plan to complete that by tomorrow. Then I am done for the year.

This is also the right time for each one of us to look back and assess how the year has been professionally and personally for us. I call it the time for personal retro (retrospective).  Obviously enjoy your holidays, but make sure that you find some time to reflect upon your performance as an individual this year ...preferably  across four domains Work/Career, Home/Family, Community/Society, Self:mind, body, spirit (as defined by Dr. Friedman). The year end performance evaluation you received is just one input.

Think about these two questions...
- What went well for you in 2009
- What could have been improved

Also, ask yourself .... have you grown this year,  or has this year helped you in moving toward your long term personal vision. Irrespective of whether your answer being either yes or no .... ask why? Do you think you should change your personal vision based on the new circumstances and/or things you learned?

Doing a retrospective of your performance this year and then prioritizing the areas of improvement, will help you figure out what you should focus on next year.

The newest addition to our family has arrived!

8 months ago | Biju Bhaskar: Thoughts on enterprise application development...

God has blessed us with a new baby boy!

Tarun Bhaskar

Arrived on December 13th,2009 at 4:29 AM
6 pounds and 12 ounces, 20 inches

What should you optimize for while staffing an enterprise transition team?

9 months ago | Biju Bhaskar: Thoughts on enterprise application development...

Recently, we were trying to find leads for an organizational change initiative that we think will take us to next level in software development. Specifically we wanted leads for four different workstreams. There were couple of view points on how to staff the enterprise transition team.

Option 1 - Lets staff folks who have shown passion in the areas we pick. Folks who have been thoughtpartners in those areas. For example, for the co-location workstream pick someone who understand the values of co-location and is passionate about it, and have even experimented with their teams.

Option 2 - Usually the same set of folks get the opportunity. This time lets give others the opportunity to lead such an initiative.

I strongly believe... folks who have been thoughtleaders and passionate about these changes should lead these initiatives. If you are passionate about anything you do, there is a great chance for making it a success, and that is important for the organization. Rewarding such folks, will also send the right message for the rest of the folks. The side benefit is that then it will require less oversight from leadership as they know exactly where we want to get to.

Having said that, I am sensitive to the fact that some folks have not gotten the opportunity to lead such initiatives. But, they are responsible for the situation they are in now. They have to show some initiative and thoughtleadership to be picked. As I always remind our folks.... this is a place where you can try and experiment whatever you want to do. Even if you try and fail, it doesn't matter. Then, why are you not trying. What are you passionate about? Find it, and run with it. We are here to support you. Show that your are real leadership material.

Anyway, in this case, we came up with a great middle ground. We ended up picking a pair for each workstream. One person who has been a thoughtleader in the area, and another person who has not got an oppurtunity before. We are also going through an exercise to make sure that everyone has a leadership opportunity for next year.

What would you optimize for in such a situation?

Cloud Computing - where do we start?

9 months ago | Biju Bhaskar: Thoughts on enterprise application development...

There is too much to read about cloud computing these days. As usual there
are many folks writing for it and some against. Its so confusing for many
of us. Sometimes its scary too...  especially the arguments being made
about security, reliability and cost. One thing I can tell you ....everyone
will be using some form of the cloud 3 to 5 years from now. So the big
question as an enterprise IT shop is, when/where should we start?

If you want to be ahead of the curve.... here are my 2 cents....

Start by testing the water. Start with couple of projects in Dev and/or QA
environments. That will help you understand first hand the pros and cons of
using cloud. Each organization is different, so what works for one may not
work for other. So why not find out yourself what works for you than
listening to all pundits who confuses you.

From my experience, many new technology projects get delayed because of
the delay in getting the development environment ready. Instead of blaming
your Infrastructure team for that, why not cater to your business needs
immediately by using cloud for dev. That way, the dev team can start
creating working software first week itself.

Even for existing technologies, I keep hearing the complaint that QA is
not similar to Production (obviously due to many interesting reasons :).
Instead of complaining, why not start using the cloud so that you can
simulate production like environment. Since it is not real production
environment, you do not have to worry about confidentiality of data.

Once you get some experience behind your belt, you can decide how and
when to use cloud for production environment....

Thoughts?

Retrospectives are boring!

11 months ago | Biju Bhaskar: Thoughts on enterprise application development...

I have been attending lot of team retros (retrospectives) as part of our effort this year to "reinvigorate continues improvement through retros". The good thing is that these teams have a consistent repeatable process. As prescribed, these teams figure out what they should start, stop or continue and come up with some action plan before starting their next sprint. This process continues every sprint...

However, one thing I observed is that even for those good teams that are doing retros diligently, it is becoming monotonous. Also, the improvements these teams are making every sprint is very small. So over a period of time the team members start to feel that these meetings are not adding enough value and end up becoming boring.

So what can they do to bring the value back in their retros? Three things...

1. Mix it up: Dont always do start, stop and continue. Rotate the facilitator,  invite external facilitator, change the format, change focus, do video conference etc. to bring some freshness. Be creative!
2. Challenge themselves with tough questions: Teams tend to be satisfied with minor improvements they make every sprint. They need to ask tough questions like .... why cant we have 100% automation or TDD?  Why cant our velocity be double? Why are we not adhering to done list all the time? etc.
3. Do proper problem solving for at least one big ticket item: Keep asking the why question, until we get to the root cause. Use problem solving techniques like 5 why's or something similar

If  teams do these things continuously, I am sure that they are going to make a leap from good to great and retros will become more interesting.

Are your retrospectives boring?

Recommended Reading

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Finally, I have been able to catch-up with my reading this summer. There are two books I liked the most and I would highly recommend...

1. "Never Eat Alone: And Other Secrets to Success, One Relationship at a Time" by Keith Ferrazzi
2. "Pragmatic Thinking and Learning: Refactor Your Wetware" by Andy Hunt

The first book is about the development of mutually beneficial relationships and the role they play in career and personal success. Ferrazzi is a master at networking and building relationships. His book is very practical and concise, explaining to the reader methods for improving current professional and social situations. It was full of insights and useful tips that one could surely pick up and put to use...

The second book was recommended by my boss. Another marvelous read. I think what I liked best about the book was it was focused on solving the hard to describe problems of organizing your thoughts, how to change the way you think to match the problem, and even how to manage your time / interruptions to get these things done. I have already started using some of his ideas by starting to use a personal/private wiki to organize my thoughts...

I love the Pragmatic Bookshelf series. Currently I am reading "Behind Closed Doors: Secrets of Great Management" by Johanna Rothman and Esther Derby...

Recommended Reading

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Finally, I have been able to catch-up with my reading this summer. There are two books I liked the most and I would highly recommend...

1. "Never Eat Alone: And Other Secrets to Success, One Relationship at a Time" by Keith Ferrazzi
2. "Pragmatic Thinking and Learning: Refactor Your Wetware" by Andy Hunt

The first book is about the development of mutually beneficial relationships and the role they play in career and personal success. Ferrazzi is a master at networking and building relationships. His book is very practical and concise, explaining to the reader methods for improving current professional and social situations. It was full of insights and useful tips that one could surely pick up and put to use...

The second book was recommended by my boss. Another marvelous read. I think what I liked best about the book was it was focused on solving the hard to describe problems of organizing your thoughts, how to change the way you think to match the problem, and even how to manage your time / interruptions to get these things done. I have already started using some of his ideas by starting to use a personal/private wiki to organize my thoughts...

I love the Pragmatic Bookshelf series. Currently I am reading "Behind Closed Doors: Secrets of Great Management" by Johanna Rothman and Esther Derby...

Are your Scrum teams getting stories "done" done?

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

I have been attending lot of scrum meetings recently and I happened to attend a Sprint review meeting of a high performing team recently. The team claimed that they committed 17 story points and delivered all. However there was a caveat to that…. the stories were only 95% done … “some minor UI tweaks and some final testing are pending”. Usually this is a red flag for me…. there is a good chance for this team to start developing a bad habit, and end up with technical debt (or lower product quality). Sticking to “done” list religiously is key for a Scrum team’s success. They should not call a story done unless it is really done done. Let me try to explain why…

A good analogy would be Toyota Production System. The concept of any employee being able to stop the line in a Toyota plant is a key part of Toyota’s quality strategy. In traditional manufacturing settings, management will pressure employees to keep the line running at all costs -- quantity over quality. If defects are being made, keep the line running and you'll sort them out at the end of the line (through inspection and repair). It's a failed quality strategy because it ultimately costs more and potentially leads to more customer dissatisfaction than if you had just stopped the line to immediately fix the problem and prevent more defects from being made. That also creates a behavior change among the employees that assures quality through out the system.

Similarly Scrum teams should avoid calling a story done if it is not really done done. If it is okay in one sprint, it becomes okay in couple of sprints and slowly could become a habit and the team will end up with technical debt (or low quality application). I know it’s hard to not give credit to the team who has done 95% of the hard work. They may hate you for couple of sprints… but they will surely thank you at the end of the release for helping them become a high performing team.

Thoughts?

Are your Scrum teams getting stories "done" done?

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

I have been attending lot of scrum meetings recently and I happened to attend a Sprint review meeting of a high performing team recently. The team claimed that they committed 17 story points and delivered all. However there was a caveat to that…. the stories were only 95% done … “some minor UI tweaks and some final testing are pending”. Usually this is a red flag for me…. there is a good chance for this team to start developing a bad habit, and end up with technical debt (or lower product quality). Sticking to “done” list religiously is key for a Scrum team’s success. They should not call a story done unless it is really done done. Let me try to explain why…

A good analogy would be Toyota Production System. The concept of any employee being able to stop the line in a Toyota plant is a key part of Toyota’s quality strategy. In traditional manufacturing settings, management will pressure employees to keep the line running at all costs -- quantity over quality. If defects are being made, keep the line running and you'll sort them out at the end of the line (through inspection and repair). It's a failed quality strategy because it ultimately costs more and potentially leads to more customer dissatisfaction than if you had just stopped the line to immediately fix the problem and prevent more defects from being made. That also creates a behavior change among the employees that assures quality through out the system.

Similarly Scrum teams should avoid calling a story done if it is not really done done. If it is okay in one sprint, it becomes okay in couple of sprints and slowly could become a habit and the team will end up with technical debt (or low quality application). I know it’s hard to not give credit to the team who has done 95% of the hard work. They may hate you for couple of sprints… but they will surely thank you at the end of the release for helping them become a high performing team.

Thoughts?

Good is the enemy of great!

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

We have been in our Scrum/Agile adoption journey for more than two years now. Last year we rolled out Scrum across all teams. We may be able to call ourselves "good" at it. In the journey towards excellence, this is the time every application development organization has to worry about. As Jim Collins put it, good is the enemy of great! It feels like we may be getting a little lazy with Scrum as we think we know everything. Not all teams are showing the discipline that was there a few months back. For example, some teams are not doing release planning properly, some does not have burn down charts, and some are not using daily stand ups for what it is meant to be, and so on and so forth. We have to do something to take Scrum to next level.

But where should we start.... as it could be anywhere ... fixing daily stand-ups, review meeting, retrospective, release planning, so on and so forth. I would start at Retrospectives. Each team is at a different level. But each team can improve from where they are today, sprint after sprint. Retrospectives are a great tool to inspect and adapt and improve every sprint as a team.... as long as teams try to understand the root cause of the issues and consistently follow-up and fix them. If you want to try some new methods to conduct a retrospective, there are great tools available in the book Agile Retrospectives. Also, once in a while it would be great if someone external from the team can facilitate the retro for the teams. I recently did one for one of our project teams, and saw the value in having an external facilitator. I will share my experience in a subsequent blog.

Finally, it is not about getting the project done. Getting it done in such a way that each member in the team feels proud about it, is the key. Scrum gives us all the right tools for doing that. If we understand the value of each tool and use them properly, we could make all good teams great!

Good is the enemy of great!

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

We have been in our Scrum/Agile adoption journey for more than two years now. Last year we rolled out Scrum across all teams. We may be able to call ourselves "good" at it. In the journey towards excellence, this is the time every application development organization has to worry about. As Jim Collins put it, good is the enemy of great! It feels like we may be getting a little lazy with Scrum as we think we know everything. Not all teams are showing the discipline that was there a few months back. For example, some teams are not doing release planning properly, some does not have burn down charts, and some are not using daily stand ups for what it is meant to be, and so on and so forth. We have to do something to take Scrum to next level.

But where should we start.... as it could be anywhere ... fixing daily stand-ups, review meeting, retrospective, release planning, so on and so forth. I would start at Retrospectives. Each team is at a different level. But each team can improve from where they are today, sprint after sprint. Retrospectives are a great tool to inspect and adapt and improve every sprint as a team.... as long as teams try to understand the root cause of the issues and consistently follow-up and fix them. If you want to try some new methods to conduct a retrospective, there are great tools available in the book Agile Retrospectives. Also, once in a while it would be great if someone external from the team can facilitate the retro for the teams. I recently did one for one of our project teams, and saw the value in having an external facilitator. I will share my experience in a subsequent blog.

Finally, it is not about getting the project done. Getting it done in such a way that each member in the team feels proud about it, is the key. Scrum gives us all the right tools for doing that. If we understand the value of each tool and use them properly, we could make all good teams great!

Getting closer to our business...

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

All of us agree that to become a successful Application development/IT organization, we need to get more closer to business...

Recently, we experimented with one of our folks from Application Development working with our business for 3 months. The insights she had into their business process, how our current products are helping/hindering the business, what are the gaps in our IT systems & support etc. were very valuable. In this case she worked in the business team as one of them. She did everything a business person would do for those 3 months.

This also gives an opportunity for IT to take some of our processes to add value to business. For example, she is planning to recommend to business to do Retrospectives at the end of their each peak business cycle. Probably IT can help facilitate the first time. Wouldn't that be great for any firm to have business and IT that closer? My dream is to have business adopt an agile/lean process like Scrum or Kanban for their day to day work.

Anyway, I think we should aggressively pursue more similar opportunities for our Business Analysts/Product Owners and others to work with business, and also have some business folks work in IT for a short duration (ideally 3 months time box). That way we would know first hand the current pains business have, and try to solve them. While doing that, business can learn some of the good IT practices as well...

Have you tried anything like this in your organization?

Getting closer to our business...

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

All of us agree that to become a successful Application development/IT organization, we need to get more closer to business...

Recently, we experimented with one of our folks from Application Development working with our business for 3 months. The insights she had into their business process, how our current products are helping/hindering the business, what are the gaps in our IT systems & support etc. were very valuable. In this case she worked in the business team as one of them. She did everything a business person would do for those 3 months.

This also gives an opportunity for IT to take some of our processes to add value to business. For example, she is planning to recommend to business to do Retrospectives at the end of their each peak business cycle. Probably IT can help facilitate the first time. Wouldn't that be great for any firm to have business and IT that closer? My dream is to have business adopt an agile/lean process like Scrum or Kanban for their day to day work.

Anyway, I think we should aggressively pursue more similar opportunities for our Business Analysts/Product Owners and others to work with business, and also have some business folks work in IT for a short duration (ideally 3 months time box). That way we would know first hand the current pains business have, and try to solve them. While doing that, business can learn some of the good IT practices as well...

Have you tried anything like this in your organization?

Consistently exceed sponsor expectations

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

This is the second of my series on the values we believe as an Application Development organization...

Let me start by defining what sponsors mean for us. As an AppDev organization, sponsors come to us with Application Development projects and we execute those projects so that we add value to the business. In our case most of them are internal clients. To take us to excellence in software development, we need to consistently exceed those sponsor expectation, so that they come back to us all the time happily, and never think of developing an application without us. As my colleague Mark puts it “Do your sponsors ask you to run an airline?” (He was referring to the zappos.com video on Nightline). We need to get to a state where our sponsors love us that much so that they ask us to run an airline. I know its hard .. but possible.

In the past (from my PMP days) exceeding sponsor expectation was all about delivering on time and on budget. Those days have gone for us. With the help of Scrum and timeboxed releases most of our projects are expected to be on time on budget. But then what is that matters? Is that scope? Not exactly… (1) setting the right scope, (2) sticking to commitments and (3) proper communication are the three things that are going to matter the most.

(1) Since scope is the only variable in the iron triangle how do we deal with it so that we exceed sponsor expectations? Its simple! Start with having a short vision for the time-boxed release by defining what business value are we going to deliver in the three months. If the project takes more than three months, break into smaller three month chunks. Make sure the stories (requirements) are prioritized to delight our users and aligned to the vision. Do release planning and tell sponsors what is possible and what is not possible in that release upfront based on the teams velocity. Understand what success criteria looks like for them. If it is not achievable, set the expectations upfront.

(2) Once you set the right expectation upfront, communicate... communicate... communicate! Scrum gives the framework for doing that. Doing Release planning, Sprint planning, daily stand-ups and sprint retrospectives the right way are key to this. Try to get time commitment from business so that they are available for the team when questions arise. I would recommend having them as part of the Product Owner team wherever possible. Similarly understanding and communicating risks are key as well.

Remember we are a service organization. We can never say “No, we can’t do it!”, or we can always say "Yes we can do it!". Instead, understand what they want and offer options so that it’s a win-win situation for everyone. Agile development gives a lot of flexibility to do this. Another important factor for success is to educate them when required. For example, if they are not aware of the benefits of automated testing, explain to them that... if they have an urgent change that needs to be done in a day, these automated tests can help them do that the same day, whereas manual testing would take few days. They will be convinced if we show them the benefits other projects have got from these kind of practices that is required for delivering quality applications.

(3) Once the team commits, it is important that we deliver most of the time. If we commit and don’t deliver, they will slowly lose trust in us. If its hard to commit due to lot of unknowns, we have to let them know that we need some more time to get more information before committing the deliverables.

Above all, what matters the most is how the team interacts with sponsors when things don’t go so well. We have to remember that every interaction is an opportunity. We can never keep them on the dark. Letting them know the bad news early and having different options or workarounds upfront would make a big difference in such situations.

These are simple things most of us know. We need to do this in every project so that we consistently exceed sponsor expectations. What are your thoughts on this?

Consistently exceed sponsor expectations

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

This is the second of my series on the values we believe as an Application Development organization...

Let me start by defining what sponsors mean for us. As an AppDev organization, sponsors come to us with Application Development projects and we execute those projects so that we add value to the business. In our case most of them are internal clients. To take us to excellence in software development, we need to consistently exceed those sponsor expectation, so that they come back to us all the time happily, and never think of developing an application without us. As my colleague Mark puts it “Do your sponsors ask you to run an airline?” (He was referring to the zappos.com video on Nightline). We need to get to a state where our sponsors love us that much so that they ask us to run an airline. I know its hard .. but possible.

In the past (from my PMP days) exceeding sponsor expectation was all about delivering on time and on budget. Those days have gone for us. With the help of Scrum and timeboxed releases most of our projects are expected to be on time on budget. But then what is that matters? Is that scope? Not exactly… (1) setting the right scope, (2) sticking to commitments and (3) proper communication are the three things that are going to matter the most.

(1) Since scope is the only variable in the iron triangle how do we deal with it so that we exceed sponsor expectations? Its simple! Start with having a short vision for the time-boxed release by defining what business value are we going to deliver in the three months. If the project takes more than three months, break into smaller three month chunks. Make sure the stories (requirements) are prioritized to delight our users and aligned to the vision. Do release planning and tell sponsors what is possible and what is not possible in that release upfront based on the teams velocity. Understand what success criteria looks like for them. If it is not achievable, set the expectations upfront.

(2) Once you set the right expectation upfront, communicate... communicate... communicate! Scrum gives the framework for doing that. Doing Release planning, Sprint planning, daily stand-ups and sprint retrospectives the right way are key to this. Try to get time commitment from business so that they are available for the team when questions arise. I would recommend having them as part of the Product Owner team wherever possible. Similarly understanding and communicating risks are key as well.

Remember we are a service organization. We can never say “No, we can’t do it!”, or we can always say "Yes we can do it!". Instead, understand what they want and offer options so that it’s a win-win situation for everyone. Agile development gives a lot of flexibility to do this. Another important factor for success is to educate them when required. For example, if they are not aware of the benefits of automated testing, explain to them that... if they have an urgent change that needs to be done in a day, these automated tests can help them do that the same day, whereas manual testing would take few days. They will be convinced if we show them the benefits other projects have got from these kind of practices that is required for delivering quality applications.

(3) Once the team commits, it is important that we deliver most of the time. If we commit and don’t deliver, they will slowly lose trust in us. If its hard to commit due to lot of unknowns, we have to let them know that we need some more time to get more information before committing the deliverables.

Above all, what matters the most is how the team interacts with sponsors when things don’t go so well. We have to remember that every interaction is an opportunity. We can never keep them on the dark. Letting them know the bad news early and having different options or workarounds upfront would make a big difference in such situations.

These are simple things most of us know. We need to do this in every project so that we consistently exceed sponsor expectations. What are your thoughts on this?

Delight our users with simple, fast and valued solutions

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Let me share my thoughts on the first item of the six important values we care about. This is the value that can have the maximum impact with all the "User Experience" (UX) initiatives that is going on in our group. Among many, there are three main things that can help us in delighting our users....

1. Simplicity.... it is very powerful! Simplicity fuels many elements of good design, including ease of use, visual appeal, and accessibility. But simplicity starts with the design of a product's fundamental functions. We shouldn't set out to create feature-rich products; our best designs should include only the features that people need to accomplish their goals. Ideally, even solutions that require large feature sets and complex visual designs should appear to be simple as well as powerful. Our teams should think twice before sacrificing simplicity in pursuit of a less important feature. Our product Owners have a big role to play here to ensure that this happens in every project. Our hope should be to evolve products in new directions instead of just adding more features

2. Every millisecond counts. Nothing is more valuable than our application user’s time. Like Google, our pages need to load quickly, with the help of slim code and carefully selected image files. The most essential features and text are placed in the easiest-to-find locations. Unnecessary clicks, typing, steps, and other actions should be eliminated. Our products ask for information only once and include smart defaults. Companies like Google consider speed as a competitive advantage that it doesn't sacrifice without a good reason. Good thing is that we have started to target less than 1 second for a web page to load from New York. But, how about the users in Moscow or Singapore... we need to ensure that they also get faster response time.

3. Focus on our users – their work, their needs. We need to discover our users actual needs, including needs they can't always articulate. With that information, we should create products that solve real user problems. Improving users lives, not just easing step-by-step tasks, should be our goal. More importantly, a well-designed product should be valuable in daily work life. It is not just user interviews that would get us there. Interviews are very important, but we need to get better at analytics (usage stats, support tickets etc.) so that we understand the needs they can’t articulate and that's how we build valuable solutions.

To summarize, we need to delight our users consistently with simple, fast and valuable solutions. We have some good initiatives like the UX interest groups internally that is helping everyone understand this important value. But we need to get to a state where each Scrum team and its PO are thinking in this way.

How are you or your organization thinking about this?

Delight our users with simple, fast and valued solutions

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Let me share my thoughts on the first item of the six important values we care about. This is the value that can have the maximum impact with all the "User Experience" (UX) initiatives that is going on in our group. Among many, there are three main things that can help us in delighting our users....

1. Simplicity.... it is very powerful! Simplicity fuels many elements of good design, including ease of use, visual appeal, and accessibility. But simplicity starts with the design of a product's fundamental functions. We shouldn't set out to create feature-rich products; our best designs should include only the features that people need to accomplish their goals. Ideally, even solutions that require large feature sets and complex visual designs should appear to be simple as well as powerful. Our teams should think twice before sacrificing simplicity in pursuit of a less important feature. Our product Owners have a big role to play here to ensure that this happens in every project. Our hope should be to evolve products in new directions instead of just adding more features

2. Every millisecond counts. Nothing is more valuable than our application user’s time. Like Google, our pages need to load quickly, with the help of slim code and carefully selected image files. The most essential features and text are placed in the easiest-to-find locations. Unnecessary clicks, typing, steps, and other actions should be eliminated. Our products ask for information only once and include smart defaults. Companies like Google consider speed as a competitive advantage that it doesn't sacrifice without a good reason. Good thing is that we have started to target less than 1 second for a web page to load from New York. But, how about the users in Moscow or Singapore... we need to ensure that they also get faster response time.

3. Focus on our users – their work, their needs. We need to discover our users actual needs, including needs they can't always articulate. With that information, we should create products that solve real user problems. Improving users lives, not just easing step-by-step tasks, should be our goal. More importantly, a well-designed product should be valuable in daily work life. It is not just user interviews that would get us there. Interviews are very important, but we need to get better at analytics (usage stats, support tickets etc.) so that we understand the needs they can’t articulate and that's how we build valuable solutions.

To summarize, we need to delight our users consistently with simple, fast and valuable solutions. We have some good initiatives like the UX interest groups internally that is helping everyone understand this important value. But we need to get to a state where each Scrum team and its PO are thinking in this way.

How are you or your organization thinking about this?

Our values!

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Finally we came up with the values to support our vision as an Application Development organization (Note that this is different from our firm's values).

To take us to “Excellence in Software Development” we would like to base our activities on the following core values…

1. Delight our users with simple, fast and valued solutions
2. Consistently exceed sponsor expectations
3. Inspire our colleagues
4. Understand best practices. Embrace next practices
5. Demonstrate software craftsmanship
6. Create the best place to work, rich with fun and passion

But, what are values? They are … what’s really important to an organization, as Konrad Knell explains in his blog. They are the essential and enduring beliefs – a small set of general guiding principles, not to be compromised for short-term expediency. Each value should be a piercing simplicity that provides substantial guidance to the members of the organization. They cannot be copied or dictated; they are what is authentically believed by the most in the organization.

Every word in each of the six sentences above matters. Now you can imagine how difficult it is to come up with it. The good thing is that we were able to share and confirm with the whole group that these are the right values for us to focus on.

I will write about these values and what it means for us in my upcoming posts…

Our values!

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Finally we came up with the values to support our vision as an Application Development organization (Note that this is different from our firm's values).

To take us to “Excellence in Software Development” we would like to base our activities on the following core values…

1. Delight our users with simple, fast and valued solutions
2. Consistently exceed sponsor expectations
3. Inspire our colleagues
4. Understand best practices. Embrace next practices
5. Demonstrate software craftsmanship
6. Create the best place to work, rich with fun and passion

But, what are values? They are … what’s really important to an organization, as Konrad Knell explains in his blog. They are the essential and enduring beliefs – a small set of general guiding principles, not to be compromised for short-term expediency. Each value should be a piercing simplicity that provides substantial guidance to the members of the organization. They cannot be copied or dictated; they are what is authentically believed by the most in the organization.

Every word in each of the six sentences above matters. Now you can imagine how difficult it is to come up with it. The good thing is that we were able to share and confirm with the whole group that these are the right values for us to focus on.

I will write about these values and what it means for us in my upcoming posts…

Do you have a personal vision statement?

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Most successful organizations have a vision, similar to the vision we have for our App Dev organization - "Excellence in software development". Similarly, each of us should have one too. Fast forward three to five years and write down now.. what you want your career to look like in 2014 (even 10 to 15 years later) or what you want to be. This could be extended later to other domains of your life, i.e. your family, self (mind, body and spirit) or your community/society etc.

This statement of your personal vision is intended to provide a focus for your long-term and short-term actions. It's expected that you will revise it over time as the environment changes and your priorities change just like any other organization. It will be of most use if your vision is a "compelling image of an achievable future, a story or picture that inspires" as my professor Stewart D. Friedman puts it.

Before you write down your goals for the year, I would recommend creating your personal vision. Then only you would know the goals you are putting for yourself this year is aligned to your personal vision. Ask yourself, "Is this going to help me get to my vision?" If not, it is not probably worth trying to achieve those goals...

Creating a personal vision has helped me a lot in deciding what my priorities should be at work. I have found it helpful to many of the folks I help with in their professional development as well.

Do you have a personal vision? If yes, how is it helping you? or I encourage you to create one and see the difference it makes ...

Do you have a personal vision statement?

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Most successful organizations have a vision, similar to the vision we have for our App Dev organization - "Excellence in software development". Similarly, each of us should have one too. Fast forward three to five years and write down now.. what you want your career to look like in 2014 (even 10 to 15 years later) or what you want to be. This could be extended later to other domains of your life, i.e. your family, self (mind, body and spirit) or your community/society etc.

This statement of your personal vision is intended to provide a focus for your long-term and short-term actions. It's expected that you will revise it over time as the environment changes and your priorities change just like any other organization. It will be of most use if your vision is a "compelling image of an achievable future, a story or picture that inspires" as my professor Stewart D. Friedman puts it.

Before you write down your goals for the year, I would recommend creating your personal vision. Then only you would know the goals you are putting for yourself this year is aligned to your personal vision. Ask yourself, "Is this going to help me get to my vision?" If not, it is not probably worth trying to achieve those goals...

Creating a personal vision has helped me a lot in deciding what my priorities should be at work. I have found it helpful to many of the folks I help with in their professional development as well.

Do you have a personal vision? If yes, how is it helping you? or I encourage you to create one and see the difference it makes ...

Have you tried Google Analytics? Its awesome!

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Even though I have heard about Google Analytics long time back, I have never tried it. Last month at the workshop I attended in San Fransisco, we used it... to learn more about where our visitors came from and how they interacted with our sites. It is very powerful and awesome! I wonder why we are not using it for our apps.

If you want to know more about Google Analytics, please go to these links
http://www.google.com/analytics/
http://en.wikipedia.org/wiki/Google_Analytics

Currently, we spend a lot of money on other products to do web analytics for us. I think it is worth trying Google analytics, as it would be very useful in user centered design & development, as well as to track usage especially for our external facing websites without much overhead. (Of course if Security Team approves it). Above all, it is totally free. I heard that lot of web analytics companies have shutdown after Google offered this for free.

One of the most interesting features I liked in their product is called "site overlay". The Site Overlay feature enables tracking of individual clicks on hyperlink URLs found on pages of a website. The report actually lays a “click map” over the pages of the site and allows us to track the exact links users click on throughout the pages of the website. This can be very beneficial in determining what links are being used and which links are completely overlooked by our users. Knowing what links are being used can help us determine if the keyword or feature we use in the link makes sense, the location of the link makes sense, or both work together or not. All of this can help us organize our page to better speak to our users and give them what they are looking for, where they are looking for it!

Have you tried it?

For those of you who are interested (and work with me at NYC), I am planning to arrange an informal lunch & learn so that I can demonstrate some of its capabilities to you. Look out for an invite soon....

Have you tried Google Analytics? Its awesome!

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Even though I have heard about Google Analytics long time back, I have never tried it. Last month at the workshop I attended in San Fransisco, we used it... to learn more about where our visitors came from and how they interacted with our sites. It is very powerful and awesome! I wonder why we are not using it for our apps.

If you want to know more about Google Analytics, please go to these links
http://www.google.com/analytics/
http://en.wikipedia.org/wiki/Google_Analytics

Currently, we spend a lot of money on other products to do web analytics for us. I think it is worth trying Google analytics, as it would be very useful in user centered design & development, as well as to track usage especially for our external facing websites without much overhead. (Of course if Security Team approves it). Above all, it is totally free. I heard that lot of web analytics companies have shutdown after Google offered this for free.

One of the most interesting features I liked in their product is called "site overlay". The Site Overlay feature enables tracking of individual clicks on hyperlink URLs found on pages of a website. The report actually lays a “click map” over the pages of the site and allows us to track the exact links users click on throughout the pages of the website. This can be very beneficial in determining what links are being used and which links are completely overlooked by our users. Knowing what links are being used can help us determine if the keyword or feature we use in the link makes sense, the location of the link makes sense, or both work together or not. All of this can help us organize our page to better speak to our users and give them what they are looking for, where they are looking for it!

Have you tried it?

For those of you who are interested (and work with me at NYC), I am planning to arrange an informal lunch & learn so that I can demonstrate some of its capabilities to you. Look out for an invite soon....

The Performance Evaluation Pryramid for '09

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Last year we evaluated all the folks in our group based on their performance in three areas. I call it the "Performance Evaluation Pyramid". I encourage all of you to think about this framework while coming up with your goals and measures for this year...


At the bottom of the pyramid is "project work", our bread and butter. Basically, how well you and your teams did your projects. Last year we did most of our projects well, and so this year the expectation is that we will be doing better. By the way, all are expected to do well in this area.

Above that is "personal growth". We would like each of you to personally grow in an area(s) you think are important for you. By the end of the year, you will have to demonstrate that you have grown in the area(s) you have chosen. This should be ideally be a stretch goal for most of you.

On the top of the pyramid is "your contribution back to the community". Here we will look at how you have given back to the community, to make others successful. The community could be internal (like CoEs, your project teams etc.) or external professional groups you are part of. I think this year there will be extra credit given to people who have ventured outside the firm and tried to learn from them, and/or have tried to teach them what we know.

My guess is that by doing all of the above by end of the year will give you a ME (Meets Expectation) rating. For ME+, someone will have to knock at least couple of the above areas out of the park. For getting a EE (Exceeds Expectations) rating you really have to be outstanding in all these areas.

I know the bar is very high. But, how many firms in the industry are asking their folks to make their personal growth to be one of the mandatory goals for this year. My guess is... very very few....especially in this economy...

The good thing is that you will have professionally grown here more... than anywhere else...

Thoughts?

The Performance Evaluation Pryramid for '09

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Last year we evaluated all the folks in our group based on their performance in three areas. I call it the "Performance Evaluation Pyramid". I encourage all of you to think about this framework while coming up with your goals and measures for this year...


At the bottom of the pyramid is "project work", our bread and butter. Basically, how well you and your teams did your projects. Last year we did most of our projects well, and so this year the expectation is that we will be doing better. By the way, all are expected to do well in this area.

Above that is "personal growth". We would like each of you to personally grow in an area(s) you think are important for you. By the end of the year, you will have to demonstrate that you have grown in the area(s) you have chosen. This should be ideally be a stretch goal for most of you.

On the top of the pyramid is "your contribution back to the community". Here we will look at how you have given back to the community, to make others successful. The community could be internal (like CoEs, your project teams etc.) or external professional groups you are part of. I think this year there will be extra credit given to people who have ventured outside the firm and tried to learn from them, and/or have tried to teach them what we know.

My guess is that by doing all of the above by end of the year will give you a ME (Meets Expectation) rating. For ME+, someone will have to knock at least couple of the above areas out of the park. For getting a EE (Exceeds Expectations) rating you really have to be outstanding in all these areas.

I know the bar is very high. But, how many firms in the industry are asking their folks to make their personal growth to be one of the mandatory goals for this year. My guess is... very very few....especially in this economy...

The good thing is that you will have professionally grown here more... than anywhere else...

Thoughts?

The 70-20-10 rule

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

I know that most of you are in the process of finalizing your PDP goals (Professional Development Plan) for this year. One of the areas in the plan is competency development. Last year I had asked many of our folks to use the 70-20-10 rule when they came up with the action plan for developing a competency. Some of you had used it and found it very useful. Thought of sharing with others...

So what is the 70-20-10 rule?

Basically, it asks you to structure your action plan in the following format:
70% is practice, practice, practice; Learning and development comes from real-life and on-the-job experiences and problem solving. For example let us say the competency you are planning to develop is to "coach others". You need to really start coaching others wherever and whenever possible. Only by doing it you are going to learn it and master the skill.

20% is feedback; It is good that you are practicing. But, how do you know that you are doing it right and you are improving. That is why getting proper feedback is the next most important thing. In the above example, one needs to have a plan to take feedback from the person whom you are coaching and/or to get feedback from an independent observer regularly.

Only balance 10% is training; Lot of us mistakenly think that training is the best way to learn new things. In this economy, other best ways to leverage this 10% is by reading books, blogs, talking to your PDL etc. about the topic.

I found the above framework very useful for me and the folks I work with. I encourage you to use the same when you are coming up with the action plan for developing a competency...

Any reactions?

The 70-20-10 rule

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

I know that most of you are in the process of finalizing your PDP goals (Professional Development Plan) for this year. One of the areas in the plan is competency development. Last year I had asked many of our folks to use the 70-20-10 rule when they came up with the action plan for developing a competency. Some of you had used it and found it very useful. Thought of sharing with others...

So what is the 70-20-10 rule?

Basically, it asks you to structure your action plan in the following format:
70% is practice, practice, practice; Learning and development comes from real-life and on-the-job experiences and problem solving. For example let us say the competency you are planning to develop is to "coach others". You need to really start coaching others wherever and whenever possible. Only by doing it you are going to learn it and master the skill.

20% is feedback; It is good that you are practicing. But, how do you know that you are doing it right and you are improving. That is why getting proper feedback is the next most important thing. In the above example, one needs to have a plan to take feedback from the person whom you are coaching and/or to get feedback from an independent observer regularly.

Only balance 10% is training; Lot of us mistakenly think that training is the best way to learn new things. In this economy, other best ways to leverage this 10% is by reading books, blogs, talking to your PDL etc. about the topic.

I found the above framework very useful for me and the folks I work with. I encourage you to use the same when you are coming up with the action plan for developing a competency...

Any reactions?

Need your help

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

As I mentioned earlier, I'm participating at Wharton this week in an intensive workshop on the development of web-based products and services. My classmates and I have developed some interesting new websites. We're very interested in having some potential users take a look at these sites and provide us with some reactions. Today is our friends and family sneak preview. Please take a look at http://www.wwwharton.com.

These are proof-of-concept prototypes intended to gauge your reactions. That information will be extremely helpful in deciding whether or not to pursue the opportunities and how to improve the approaches. While your actively providing feedback is certainly welcome, simply visiting the site gives us valuable statistical information as well.

Thanks very much.

Need your help

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

As I mentioned earlier, I'm participating at Wharton this week in an intensive workshop on the development of web-based products and services. My classmates and I have developed some interesting new websites. We're very interested in having some potential users take a look at these sites and provide us with some reactions. Today is our friends and family sneak preview. Please take a look at http://www.wwwharton.com.

These are proof-of-concept prototypes intended to gauge your reactions. That information will be extremely helpful in deciding whether or not to pursue the opportunities and how to improve the approaches. While your actively providing feedback is certainly welcome, simply visiting the site gives us valuable statistical information as well.

Thanks very much.

Good bye 2008

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Hope you are having great holidays, spending some good time with your family & friends, and be able to reflect on 2008 : )

I certainly had.... last few days have been really great. It has been a while since I have spend some quality time with my family & friends... especially my son( 5 year old).

It is going to be busy (in a good way) two weeks ahead for me. I am going on a cruise tomorrow, and next week I will be in San Francisco for a Wharton workshop on "Development of Web-Based Products and Services" conducted by Prof. Karl Ulrich. I am really exited about both.

Details on the workshop to follow....

Wish you all a very Happy New Year!

Good bye 2008

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

Hope you are having great holidays, spending some good time with your family & friends, and be able to reflect on 2008 : )

I certainly had.... last few days have been really great. It has been a while since I have spend some quality time with my family & friends... especially my son( 5 year old).

It is going to be busy (in a good way) two weeks ahead for me. I am going on a cruise tomorrow, and next week I will be in San Francisco for a Wharton workshop on "Development of Web-Based Products and Services" conducted by Prof. Karl Ulrich. I am really exited about both.

Details on the workshop to follow....

Wish you all a very Happy New Year!

Need more "Real" Product Owners

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

As I have mentioned early, we are in the process of becoming an agile/Scrum organization. As you know PO is a very important role in Scrum. We need more "real" product owners (PO) to be a successful agile organization...

So far, we have been assigning POs at the beginning of each project, not for a product. They are usually BAs who are trying their best to represent business by playing the PO proxy role. Once the project is done, the ownership is passed to support organization, who are busy with supporting the application. No one is currently owning the entire product lifecycle.

To be an effective PO, you must either be from business, or be in a position to accurately represent the business. In our world, it is usually tough to have someone from business be the PO. So ideally... a PO should be owning the entire product lifecycle as following..

• Conduct user research & interviews, drive product adoption, review support issues, review and understand usage patterns etc.
• Maintain and prioritize Product Backlog & Roadmap
• Work with Program Manager to create business case for a project
• Work closely with Dev team to develop product increments; Continuously maintain & prioritize Backlog based on user feedback
• Ensure delivery of incremental value to business
  

If they dont know the business, users, and the product how can they be an effective and real PO?

Also, I think.. POs would need a blend of the skills usually separated by traditional roles like BA,UX, PM etc. ...Jack of all trades. I will blog more about that later...

Need more "Real" Product Owners

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

As I have mentioned early, we are in the process of becoming an agile/Scrum organization. As you know PO is a very important role in Scrum. We need more "real" product owners (PO) to be a successful agile organization...

So far, we have been assigning POs at the beginning of each project, not for a product. They are usually BAs who are trying their best to represent business by playing the PO proxy role. Once the project is done, the ownership is passed to support organization, who are busy with supporting the application. No one is currently owning the entire product lifecycle.

To be an effective PO, you must either be from business, or be in a position to accurately represent the business. In our world, it is usually tough to have someone from business be the PO. So ideally... a PO should be owning the entire product lifecycle as following..

• Conduct user research & interviews, drive product adoption, review support issues, review and understand usage patterns etc.
• Maintain and prioritize Product Backlog & Roadmap
• Work with Program Manager to create business case for a project
• Work closely with Dev team to develop product increments; Continuously maintain & prioritize Backlog based on user feedback
• Ensure delivery of incremental value to business
  

If they dont know the business, users, and the product how can they be an effective and real PO?

Also, I think.. POs would need a blend of the skills usually separated by traditional roles like BA,UX, PM etc. ...Jack of all trades. I will blog more about that later...

Would you map the current roles (PM, BA) to Scrum roles?

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

As I may have mentioned earlier, we are in the process of rolling out Scrum firm wide. Almost two years into the journey now. One question that we continue to struggle with answering as an organization is... whether we should map our current PM and BA roles to Scrum Master(SM) and Product Owner (PO) role respectively? For me, the answer is a big "NO".

Every project would need a Product Owner and a Scrum Master. Ideally for staffing someone, we should look at who is the right fit to play that role based on the skills required for that role, complexity/risks in the project, required functional/technical expertise, learning/development opportunity for the individual, etc. It does not matter if you are a BA or PM and for that matter even an Architect or Developer. But, why?

Let us take the case of a BA. She may be a great BA, but those skills do not mean that she can be a good PO. PO is much more than business analysis, it is more of understanding what users want, writing user stories, backlog management, prioritization, facilitation, getting continuous user feedback etc. Similarly SM is a big shift for lot of traditional PMs. SM is more of coach, servant leader and an impediment remover. There is no room for command and control anymore. So if we want our folks to be successful, we should staff them based on the skills that are required for playing the role, or based on the skills we want them to develop.

My guess is that only a very small percentage of BAs and PMs would be able to play the new roles successfully from day one. Most of them will be able to develop the required skills slowly and become successful. But there will be some who cannot, and don’t want to make the shift to the new roles and they will leave the firm as we have seen in my organization (very very small percentage though).

How have you approached this issue in your firm?

Would you map the current roles (PM, BA) to Scrum roles?

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

As I may have mentioned earlier, we are in the process of rolling out Scrum firm wide. Almost two years into the journey now. One question that we continue to struggle with answering as an organization is... whether we should map our current PM and BA roles to Scrum Master(SM) and Product Owner (PO) role respectively? For me, the answer is a big "NO".

Every project would need a Product Owner and a Scrum Master. Ideally for staffing someone, we should look at who is the right fit to play that role based on the skills required for that role, complexity/risks in the project, required functional/technical expertise, learning/development opportunity for the individual, etc. It does not matter if you are a BA or PM and for that matter even an Architect or Developer. But, why?

Let us take the case of a BA. She may be a great BA, but those skills do not mean that she can be a good PO. PO is much more than business analysis, it is more of understanding what users want, writing user stories, backlog management, prioritization, facilitation, getting continuous user feedback etc. Similarly SM is a big shift for lot of traditional PMs. SM is more of coach, servant leader and an impediment remover. There is no room for command and control anymore. So if we want our folks to be successful, we should staff them based on the skills that are required for playing the role, or based on the skills we want them to develop.

My guess is that only a very small percentage of BAs and PMs would be able to play the new roles successfully from day one. Most of them will be able to develop the required skills slowly and become successful. But there will be some who cannot, and don’t want to make the shift to the new roles and they will leave the firm as we have seen in my organization (very very small percentage though).

How have you approached this issue in your firm?

Obama proves the power of OpenSource

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

I was in a call with Michael Tiemann, VP for OpenSource Affairs at Red Hat as part of the OpenSource related project I am working on. He mentioned that he recently blogged about how Obama proved the power of OpenSource. Check this out..it is interesting.

Obama proves the power of OpenSource

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

I was in a call with Michael Tiemann, VP for OpenSource Affairs at Red Hat as part of the OpenSource related project I am working on. He mentioned that he recently blogged about how Obama proved the power of OpenSource. Check this out..it is interesting.

Time boxing releases

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

This year has been great for us as an application development organization especially when it comes to project delivery. Most of our projects were delivered on time and on budget. You may be wondering how is that possible? Here is the trick..

Many factors contributed to the success. However, I attribute a great part of that success to two things: time boxed releases and intact teams. All our projects are now not more than three months long. When we start a new project, we set the expectation with the project team and the stakeholders that this project cannot go one day more than three months. This does a lot of good things. Since we know the burn rate of the team, the budget is fixed. The only thing that is negotiable is scope. Time boxing forces sponsors to prioritize the stories/requirements, and this makes sure that only high business value stuff gets done. So at the end of the project usually sponsors are happy because their high priority stuff got done. In the past these projects used to go on for ever until the sponsors exhausted their list, which includes nice-to-have stories. This also overcomes procrastination, sharpens the focus and increases motivation for the team.

Having said that, the key for teams is how they communicate this to the sponsors. If you tell them that we are going to pull the plug after three months, that usually creates panic and unnecessary push back from them. Instead, I would tell them that as an app dev organization we have decided to time box all our projects to three months. If you have highly critical requirements that wont fit into this release, we can have another release/project immediately following the first one. That kind of message usually does the trick and I have seen it work for many of our teams.

Some would say that this will work only for maintenance projects. In fact some of our teams have made this work for large greenfield projects. We broke those projects into three month chunks and made sure that the team delivers working software while adding some business value.

Have you tried anything similar?

Time boxing releases

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

This year has been great for us as an application development organization especially when it comes to project delivery. Most of our projects were delivered on time and on budget. You may be wondering how is that possible? Here is the trick..

Many factors contributed to the success. However, I attribute a great part of that success to two things: time boxed releases and intact teams. All our projects are now not more than three months long. When we start a new project, we set the expectation with the project team and the stakeholders that this project cannot go one day more than three months. This does a lot of good things. Since we know the burn rate of the team, the budget is fixed. The only thing that is negotiable is scope. Time boxing forces sponsors to prioritize the stories/requirements, and this makes sure that only high business value stuff gets done. So at the end of the project usually sponsors are happy because their high priority stuff got done. In the past these projects used to go on for ever until the sponsors exhausted their list, which includes nice-to-have stories. This also overcomes procrastination, sharpens the focus and increases motivation for the team.

Having said that, the key for teams is how they communicate this to the sponsors. If you tell them that we are going to pull the plug after three months, that usually creates panic and unnecessary push back from them. Instead, I would tell them that as an app dev organization we have decided to time box all our projects to three months. If you have highly critical requirements that wont fit into this release, we can have another release/project immediately following the first one. That kind of message usually does the trick and I have seen it work for many of our teams.

Some would say that this will work only for maintenance projects. In fact some of our teams have made this work for large greenfield projects. We broke those projects into three month chunks and made sure that the team delivers working software while adding some business value.

Have you tried anything similar?

Team based performance evaluations

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

It is that time of the year again... Evaluation season. I am yet to start writing evaluations for my direct reports. Right now I am in the process of writing references for the folks who have asked me for it. While doing so the same nagging thought that haunted me last year reappeared ... is individual performance review the right way to do this. Probably not!

In our organization all the work is done by teams. Then why don't we reward teams instead of individuals? It seems like we are rewarding someone for their individual performance than for their team work, when all what we need is high performing teams.

Some may argue that there are some issues with team based performance evaluation. Here is one question I got from some of the folks I pitched this idea.... How will we form the teams?

There are many ways to do it. For example.. In the beginning of the year .. create a pool of people that includes FTEs (Full Time Employee) and vendor contractors with different skills (Scrum Masters, Product Owners, Architects, Developers etc.). We can create some basic rules like not more than two FTEs can be part of a team, and then ask everyone to self form teams. Teams can think about technology areas and functional areas as criteria to define team attributes. Keep the teams intact for rest of the year and at the end of the year, evaluate the teams and have the team members evaluate each other. The key for these teams is to self-organize and self- manage themselves. If someone is not doing well in the team and is getting a free ride the team should be able to vote him/her out.

I know it sounds a little bit radical. I am confident about the success though. This year I have been pushing hard on having "intact teams" and as an app dev organization we saw the value of having intact teams. Our internal clients love them. The start-up time for a new project has considerably reduced due to these teams as they have already passed the forming, storming and norming stages of team formation. These teams seem to knocking project after project out of the park. Our vendors and vendor employees also love it as we are giving them a long term commitment.

What are your thoughts on this topic?

By the way there was an interesting article on WSJ today..
Get Rid of the Performance Review!It destroys morale, kills teamwork and hurts the bottom line.

Team based performance evaluations

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

It is that time of the year again... Evaluation season. I am yet to start writing evaluations for my direct reports. Right now I am in the process of writing references for the folks who have asked me for it. While doing so the same nagging thought that haunted me last year reappeared ... is individual performance review the right way to do this. Probably not!

In our organization all the work is done by teams. Then why don't we reward teams instead of individuals? It seems like we are rewarding someone for their individual performance than for their team work, when all what we need is high performing teams.

Some may argue that there are some issues with team based performance evaluation. Here is one question I got from some of the folks I pitched this idea.... How will we form the teams?

There are many ways to do it. For example.. In the beginning of the year .. create a pool of people that includes FTEs (Full Time Employee) and vendor contractors with different skills (Scrum Masters, Product Owners, Architects, Developers etc.). We can create some basic rules like not more than two FTEs can be part of a team, and then ask everyone to self form teams. Teams can think about technology areas and functional areas as criteria to define team attributes. Keep the teams intact for rest of the year and at the end of the year, evaluate the teams and have the team members evaluate each other. The key for these teams is to self-organize and self- manage themselves. If someone is not doing well in the team and is getting a free ride the team should be able to vote him/her out.

I know it sounds a little bit radical. I am confident about the success though. This year I have been pushing hard on having "intact teams" and as an app dev organization we saw the value of having intact teams. Our internal clients love them. The start-up time for a new project has considerably reduced due to these teams as they have already passed the forming, storming and norming stages of team formation. These teams seem to knocking project after project out of the park. Our vendors and vendor employees also love it as we are giving them a long term commitment.

What are your thoughts on this topic?

By the way there was an interesting article on WSJ today..
Get Rid of the Performance Review!It destroys morale, kills teamwork and hurts the bottom line.

Role of External Coaches

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

We are in the process of rolling out Scrum firm wide. We are almost two years into the journey. We would not have achieved our current maturity in Scrum without the help of External coaches. In the beginning itself we decided to partner with some of the big names in the Scrum world. Selling to others in the organization becomes much easy when it comes from external coaches. What is your experience in this?

Role of External Coaches

about 1 year ago | Biju Bhaskar: Thoughts on enterprise application development...

We are in the process of rolling out Scrum firm wide. We are almost two years into the journey. We would not have achieved our current maturity in Scrum without the help of External coaches. In the beginning itself we decided to partner with some of the big names in the Scrum world. Selling to others in the organization becomes much easy when it comes from external coaches. What is your experience in this?

My Company.

over 2 years ago | Biju Bhaskar: Thoughts on enterprise application development...

Here is a quick overview of my organization. I work for a large global company where IT is not our core business. I am part of the Global application development (GAD) group in my comany. This group has gone through lot of changes in the past few years. We have consolidated almost seven different groups of similar size to a single group for Global Application delivery. Most of the applications we develop and maintain are for internal use. Only very few apps are used by our clients. Our vision is to achieve excellence in enterprise application development.

Ours is a very flat organization (less hierarchy). Primarily all members of GAD are either a Project Manager, a BA or an Architect. Most of the development is done with the help of different vendors onshore and offshore.

My Company.

over 2 years ago | Biju Bhaskar: Thoughts on enterprise application development...

Here is a quick overview of my organization. I work for a large global company where IT is not our core business. I am part of the Global application development (GAD) group in my comany. This group has gone through lot of changes in the past few years. We have consolidated almost seven different groups of similar size to a single group for Global Application delivery. Most of the applications we develop and maintain are for internal use. Only very few apps are used by our clients. Our vision is to achieve excellence in enterprise application development.

Ours is a very flat organization (less hierarchy). Primarily all members of GAD are either a Project Manager, a BA or an Architect. Most of the development is done with the help of different vendors onshore and offshore.

Finally it is happening...

over 2 years ago | Biju Bhaskar: Thoughts on enterprise application development...

Finally I decided to take the plunge and start blogging. It took me only 5 minutes to get my blog up and running. Thanks to blogger....

Finally it is happening...

over 2 years ago | Biju Bhaskar: Thoughts on enterprise application development...

Finally I decided to take the plunge and start blogging. It took me only 5 minutes to get my blog up and running. Thanks to blogger....