I am a big fan of Tony Hsieh, the CEO of Zappos. One of their company values is to "deliver wow through service". Isn't that amazing?Here is a great post on how Zappos scales customer satisfaction. If you don't have time to read the whole article, skip to "I just want a Pizza" story at the end. Its a must read..Why cant we deliver "wow" instead of projects, applications or services like Zappos? May be not to the level Zappos does. But we definitely can make our users say "wow" if we go an extra mile on anything we deliver.Thoughts?
One of the things I am passionate about and I have been working on in my new assignment is to create the next set of leaders from the managers we have. It is a big mental shift for lot of folks. For some it is a great opportunity to learn new skills and become a leader. For very few others it feels like losing their power and losing everything they have created for themselves in the organization. Anyway, I don't expect everyone to make the cut : )One rule of thumb I gave them was to check how free their calendars were. This tip was given to me by my boss years back. That is a good measure of how much of a micro manager you are. If you are in every meeting, that means that your calendar is full, and most importantly you don't trust the folks to make decisions. Start by not attending few meetings even if you are uncomfortable with it. Empower the team to make the right decision. If you worry that the team is not going to make the right decision, tell the team what you care about... I call it "drawing the box of constraints"... and let them make the decisions within the box so they feel ownership of it. It frees up your time so that you can think more about the big picture...No doubt, its a tough skill to learn.... I am still learning this art of figuring out how much to get involved...How free is your calendar : )
Wow! That is a real bold statement from any CEO, especially from that of an Indian company... This is actually the title of an awesome must read book written by Vineet Nayyar, the CEO of HCL, an Indian IT giant. Indians having grown up seeing only statements like "Customer is the king" "Customer is God" etc, this could be a shocking statement for many. His approach transformed the company... and made them the number one in employee satisfaction and has made HCL one of the fastest-growing and profitable global IT services companies.His approach is very similar to some of the ideas we strongly believe in here. Tranforming traditional command and control managers to leaders (servant leaders) and empowering the folks who really do the work (or create value) is the only way to create a world class organization today. Gone are the days of traditional management style using command and control. It is great to see another example of why this idea works really well..
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?
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...
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?
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/agilencr2010Here is the abstract of my talk:Agile 2.0 - Our Road to MasteryAn 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.
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
There is a great article posted by the CTO of Cisco, Padmasree Warrior, about the next generation collaborative enterprise...http://blogs.cisco.com/news/comments/the_next_generation_collaborative_enterprise/It made me think about how our organization will look in a few years time. I think we have all the right characteristics to be ahead of the curve and get there soon (right people, collaborative culture, agile mindset etc.). Specially I liked her comment about the real meaning of collaboration... "It is important to point out that collaboration must not be confused with consensus or teamwork. Collaboration does not mean everyone must agree before any decision is made. Nor does it suggest that there is no room for individual creativity"Makes total sense..
Leaders influence teams in subtle and indirect ways. Great post from Mike Cohn... http://bit.ly/6iRRqhHave 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.
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...
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 improvedAlso, 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.
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?
There is too much to read about cloud computing these days. As usual thereare many folks writing for it and some against. Its so confusing for manyof us. Sometimes its scary too... especially the arguments being madeabout security, reliability and cost. One thing I can tell you ....everyonewill be using some form of the cloud 3 to 5 years from now. So the bigquestion 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 QAenvironments. That will help you understand first hand the pros and cons ofusing cloud. Each organization is different, so what works for one may notwork for other. So why not find out yourself what works for you thanlistening to all pundits who confuses you.From my experience, many new technology projects get delayed because ofthe delay in getting the development environment ready. Instead of blamingyour Infrastructure team for that, why not cater to your business needsimmediately by using cloud for dev. That way, the dev team can startcreating working software first week itself.Even for existing technologies, I keep hearing the complaint that QA isnot similar to Production (obviously due to many interesting reasons :).Instead of complaining, why not start using the cloud so that you cansimulate production like environment. Since it is not real productionenvironment, you do not have to worry about confidentiality of data.Once you get some experience behind your belt, you can decide how andwhen to use cloud for production environment....Thoughts?
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...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! 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.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?
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..."Never Eat Alone: And Other Secrets to Success, One Relationship at a Time" by Keith Ferrazzi"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...
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?
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!
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?
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?
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 features2. 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?
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 passionBut, 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…
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 ...