Guilty as charged

I multitask and can do it well. Really well.

I put hours at work, I blog, I write, meet lovely friends, keep in touch with everybody and barely give anyone the chance to complaint.

The last few months, I have stopped multitasking. Not really deliberately, it just happened. Work was crazy and by the time I was home I didn't feel like doing hundred more things. I wanted time for myself, sometimes doing nothing.

And I felt guilty, especially about not being able to meet friends or writing my blog like I used to do. I wanted to be away from my laptop. I even stopped browsing. I stepped away.

I probably haven been writing but every day I am full of guilt that I haven’t been doing what I should have. I see other bloggers or professionals who are doing well, so inspired, so full of energy and I still don’t feel like writing.

It could be writers block, it could be doing the same thing for so many years now or it can be just wanting some time for myself.

Today, I browsed through some articles and wanted to know if there are more people like me who feel the same. Or am I just losing my fire?  

I read about mothers feeling guilt , about difference in the way men and women approach work  and multitude of other stuff.

Bottom-line, yes we should be responsible in what we do but I just feel sometimes it’s okay to do random stuff out of the daily routine. It’s okay to want some time for yourself to get recharged and then be back or choose not to be. Enough of guilt!

So yes I have been spending some time doing nothing except regular work. And to my all my readers if you have expected articles and seen the same one and no new updates over and over again- I was busy in my balcony looking at the mango tree and sky and birds. I was spending more time with myself than with anything else, definitely not my laptop.  

Have you been through same situations may be in different context?

I am hoping I will be writing very soon, but bear with me if it takes time- blogging is tough.  Meanwhile enjoy your schedule and what you are happy doing and if you are not- take a break minus the guilt.  It will certainly help!

(Pic Courtesy: Soma)

Scrum Team has stabilized- what next?

Most transformations start with the basic idea of either getting teams to start working in Agile or streamlining their existence process.

At a certain point, teams stabilize, velocity improves, quality soars and things look up.

Is the goal to repeat the same cycle day after day or is there more to work through once the team stabilizes? I have always though that the trying to get teams working in Agile is more like a bicycle- if you stop pedaling, it stops.

Here are 5 things to consider as next steps to keep the team going:

• Baseline velocity- Always know your baseline velocity, when you started and ways you can work on it.
• Focus factor- when the team stabilizes, it’s a good idea to know if the team has the right focus. Its velocity/work capacity. For more info read Jeff Sutherlands article here .  
• Failure trends and patterns- The commitment made by the team always doesn't match the outcome. Looking into why stories fail and trying to identify a pattern might lead the team to understand the underlying problem. It could be user stories that require infrastructure, it can be kind of stories that haven’t been worked on, it can be a story requiring a new technology.  Once you have identified the pattern, it becomes quite easy to find a resolution.
• Estimations- If in every sprint more than 20 percent of stories remain not done, along with other factors you might want to have a look at the way estimation is being done by the team. Some teams commit more by underestimating stories in trying to please the management and keeping to the team’s velocity. Of course by the end of the sprint teams fail to deliver. There are more managers and Product Owners who always push the team to commit more, so they have enough work on hand ever sprint fearing lesser work meaning team members might be free most of the time. Bottom-line, under estimating doesn’t help as much as over estimating doesn't.
• Linking and tracking the layers- Stop looking only at team levels and start looking at the bigger picture, look into the your program and portfolio management and how it  is coming down to the team. Look into the quality of the user stories and how everything is affecting the team.

(Pic Courtesy: Google Images)

To learn about how to get into project management read my book Stepping into Project Management (Welcome to the #PMOT World). To connect with experienced Project Manager's from all over the world, get mentored or shadow for a day see the SIPM Community.

Interview with Siddharta Govindaraj

Today we interview Siddhartha Govindraj, who specializes in Lean/Agile processes for software development. He has also contributed in the book "Beyond Agile: Tales of Continuous Improvement" published by Modus Cooperandi Press, Feb 2013 and Published in the March 2011 issue of the Cutter IT Journal on "Use of Kanban in Distributed Offshore Environments". An occasional organizer of events as a part of Chennai Agile User Group and speaks in conferences in India and abroad.

He was nominated for the Brickell Key award in 2011, an award given by the Lean Software & Systems Consortium for recognizing achievements in the lean-agile industry and is also a Fellow of the Lean Systems Society.

He is very interested in the behavior of decentralized and distributed systems.

Agile becoming mainstream now, how do you think the world of project management has changed?

In one way, yes….. definitely more and more organizations are seeing the value of agile in terms of incremental development and faster time to market. However, there are a few aspects where agile is still to make a significant mark. First, the people aspect of agile has still not fully permeated into the culture of many organizations. The idea that motivated, self-organized teams can deliver better software is not yet in the mainstream. I also think that many companies need to invest in the technical environment. The third aspect that companies often neglect is looking at delivery as an end to end system in the organization. Agile is often applied at the team level, and systemic impediments are not fixed. So there is still a long way to go. 

While older companies have a tough time with transformation, the good news is that newer companies like Facebook have been agile right from the start. Over the next decade, success of these newer companies will establish the culture for the whole industry.

As someone who creates tools for Agile and Lean project environments, please tell us what according to you is the most important: the tool or the expertise of the project manager?

Of course the expertise of the people in the project is the primary criteria for success. Where tools will help is in aiding decision making so that people (both within the team, and management) have better insights to take better decisions. 

This questions also leads to an interesting difference between agile project management tools and traditional project management tools. In agile, a lot of decisions are taken by the self-organized teams. Hence the tools need to be able to support the needs of the team. If the team decides that the tool is an overhead or is not adding value to them, then it becomes worthless. By contrast, the primary need of traditional tools is targeted towards managers, who are the decision makers to micromanage the team. 

A big problem is when an agile tool is used in a traditional way – i.e. the team does not feel the value, but is forced to use it so that the managers can micromanage them. My personal opinion is that tools that encourage this behavior rarely lead to truly agile culture. 

Tell us why you decided to create your software and did you use agile way of managing it while n development?

The previous answer has some insight into why we launched our tool. We saw that many organizations implemented tools which support agile mechanics, but not the agile mindset. Such tools get deployed, teams hate to use them but are forced to do so because the management doesn't trust the team and wants to control exactly what is going on in the team. Well, guess what? The team only updates the tool rarely and the data is unreliable so it helps nobody. This does not help build an agile culture. 

What we wanted to do was to build a tool that a team will find easy to use and useful for their own self organization. Basically, we took traditional, proven methods that teams use in a physical space -- card walls, task boards, story maps and so on, and made them available in an electronic format. This gives the benefit of electronic tools, while still being in a format that teams find useful for themselves. 

What according to you are the 3 qualities that every Agile Project Manager should have?

First, curiosity to keep learning. Secondly, soft skills to connect with people (within the team and outside) and build relationships. Finally, the ability to influence people and drive change and improvement. 

I haven't said anything about knowledge of agile. This is easy to learn, and anyone can learn what a product backlog is and how a particular process works. But the qualities above are difficult to train, and very crucial for agile success.

If someone new, stepping into Agile Project Management asked you about the 3 books to read, what would you recommend?

My favourite three books are:

1. Agile Software Development -- Alistair Cockburn (Quick note: This book isn’t about agile, but methodologies in general. It’s a great background about how and why agile works, but perhaps not what you are looking for if you want to know specific mechanics like how to story point a story)

2. The principles of product development flow -- Donald Reinertsen 

3. Kanban -- David Anderson

Where can someone find the link to your software and your books?

My site is at http://toolsforagile.com. I blog at http://toolsforagile.com/blog/ , 

I've also been a contributor to this book - http://amzn.to/beyond_agile

Thank you very much for your time.

Does Agile mean NO Managers?

In trying to move in the right direction Agile-wise too soon, there are organizations who will consider removing managers or team leads completely from the equation.

However, removing the title doesn't mean, the role or the job has been removed and these management positions are simply disguised via different names. There are scrum masters sometimes who are actually functional managers for the team.

I think the reason these roles overlap is because sometimes organizations don’t realizes the role of a scum master.

A scrum master is the facilitator for the team and does not make decisions for the team. I think this is the trickiest factor that no management realizes. Scrum master isn’t the decision maker or someone who will appoint stories or tasks to the team. So a manager cannot disguise himself into this role.

So, one way to resolve this problem is to never merge both of these roles. Scrum master and the functional manager shouldn't be the same person. Even by overlapping roles for one team, you send out the wrong message to the other teams.  

The managers can happily co-exist with the agile teams and they can be great blocker resolvers. They should be the one helping teams deliver more by removing all impediments, looking into the patterns and trend of all teams and see what can be done to minimize the recurring causes of the issues.  

If management interferes and spoon feeds teams in every chance they get, teams never come close enough to becoming self-organizing teams and making their own decisions. Management can choose to either make teams adopt Agile better or make decisions that messes it u for the organization. 

(pic courtesy: google images)

3 Simple Rules of Life

(Pic Courtesy: Pinterest)

Interview with Laura Dallas Burford

I hope all of you are having an amazing year 2014, today we interview Laura Dallas Burford; who is a vision mover with domestic and international experience who focuses on partnering with management by aligning strategy and projects. She has experience with big four consulting organizations; was a managing director at a start-up international technology consulting organization; and currently is the owner of LAD Enterprises, a management consulting company. Over her career, she has worked for or provided consulting advice to several Top 100 corporations and led numerous large multi-million dollar information technology and business improvement programs, outsourcing efforts, start-up initiatives, and project turnarounds. Currently, she provides project related services and training to assist organizations in realizing their goals and is a Certified Project Management Professional (PMP®

Please tell us how you became a project manager?

I became a project manager early in my career. I was in a management-training program at top US Corporation and working as a programmer/analyst when a project manager resigned. Because of my experience, Management felt I could do the job and assigned me the role of project manager for a cost accounting system. It was great experience but in the early 1980's, project management was not a specialized field of study. Outside of information for engineers on managing projects, there was with limited information for business or technical project managers so much of my project management training was on the job.

What has been the most challenging for you as a project manager? 

This is a tough question because every project has its own challenges. Two common project management issues that I continually struggle with are estimating the level of effort and duration when working with a team of all part-time team members, a topic discussed in the book, and working with first time project team members with limited or no project management knowledge, which is one of the reasons for the book.

However, as a project leader, I have found the most challenging aspect of project management is the building a productive and high quality team. Every project manager has been trained to build a team with the right skills and knowledge. Every project manager strives to have a team that works towards a common goal. However, building the right team is more than assigning people with the right skills and knowledge because the best teams are those where all team members feel that they are making a meaningful contribution and are satisfied with the job. To create such a team takes time and requires communication, collaboration, and compromise with a project sponsor, potential team members, functional managers, and even corporate human resources. Not assigning a person to the team, even if they have the right skills and knowledge, can be the best and right option for both the person and project.

What was the most challenging project you even managed and why?

My most challenging project was writing and getting Project Management for Flat Organizations published because I moved from the role of project manager, managing my writing efforts, to becoming a client of the publisher with client expectations. I was looking at the production effort as a project, a unique event with a specific start and end date while the publisher considered the effort an operational activity. As the book progressed through the production process, different people became involved and the understanding of expectations changed highlighting the importance of communicating.

 
Your recent book "Project Management for Flat Organizations" is one of ten winners of the 2013 Small Business Book Awards. Why did you decide to write the book?

The idea to write this book developed over time and is based on experiences with client projects and project management courses I teach. The attendees in the courses vary but tend to be new project managers with little or no formal training in project management, project team members, business leaders, functional managers, and project sponsors—all of whom are looking for something to assist them with their job so that they can successfully define, plan, and work a project.

Among all the available project management books, why do you think this is the one that will help newbies understand what they need to know about project management?

My book provides a simple, no-nonsense, cost-effective approach to project management. It explains the fundamentals of project management and then walks the reader through the entire project life cycle from management concept to completing the project. The book focuses on three critical activities: the first key activity is the defining of the project outcome and the recording of that definition in a scope statement (or project definition); the second activity is to plan what needs to be done and create a project plan documenting what needs to occur to accomplish the outcome; and the third activity is to “work the plan,” successfully delivering the outcome with the aid of a status report.

The book does not focus on nor was it written for people focused on sitting for a certification examination; rather it is a basic book that a person new to project management can understand and use as a reference tool when managing any type of project.

It appears that the 7 sections and 22 chapters cover everything that a person working on a project needs to know about project management.  Was this your goal? 

Use of the work “everything” suggests comprehensive coverage of project management. This was not my goal though I intended to provide a comprehensive introduction to project management for novice readers. The book builds on three critical activities—defining the project; planning the project; and working the plan—and is divided into 7 sections with 22 chapters. Each chapter is short and easy to read enabling the reader to focus on the chapters that are important to him or her without reading the entire work.

The beginning of each section provides an overview of information to be covered, a brief explanation as to the importance of the section, and a description of each chapter within the section. Each chapter starts with a list of the subjects covered, and ends with a review of key points and step-by-step instructions. The theory of the subjects is introduced and then, using examples, visual aids, tools, and techniques, the chapter walks the reader through applying the theory. Included in the chapters are short stories, scenarios, suggestions, reference tables, questions to consider, and guidelines intended to illuminate the subject, issues, or skills.

Where can your book be found, if someone wants to purchase.

The book is available from J. Ross Publishing, Amazon, Barnes & Noble and any Indie Book Store. Reviews of the book can be found on Amazon’s site .

A downloadable copy of Chapter 7: Define the Project Scope and three free downloads, known as WAV files, associated with the book:
•Project Management Word Templates (templates that are referenced throughout the book)
•Selecting a Project Management Software Application—A Whitepaper
•Ten Steps to Create a Project Management Methodology—A Whitepaper
are available at J. Ross Publishing Sign-in is required for the WAV files.

Additionally, the book is available as an e-book (i-bookstore)

Thank you Laura.

Merry Christmas!

Why Agile Transformation Fails?

Originally published at Xebia Blog

Organizations move into Agile because it sounds cool, team’s wants to transform and deliver more, have collaborative culture and make work fun. Very few actually look into the changes that will be required to bring in to make the transformation successful.

The first resistance initiates with the need to change. Change means new learnings and probably more of un-learmings.  

Most successful projects need a shift in cultural mindset; everyone wants the change but no one wants to work for it. Even in the best of conditions and work environment, very few organizations can bring in the culture of constant learning and improvement and keep everyone motivated.

To know why transformation is not the most popular thing at ground level:

• Disrupts the comfort factor- change is never comforting because it requires everyone to work for it. Most senior members and managers are more resistant to change than new members. Why try out new thing when he old one works fine.
• No zeal and capacity- its proven that just being intelligent isn’t enough for achieving higher things  . The zeal and capacity that are required from every team member to make teams successful is very difficult to inculcate unless they are inherently in the person. 
• The Dunning Kruger Effect- where individuals think they are better than the rest and hence no need to change. In situations like these where the resistant to change increases, transformation is more and more difficult to bring about. 
• Not praised for the effort during the process of transformation- 50 milliseconds after a mistake (which aren’t uncommon during new learnings), the first reaction called Error related negativity which is an involuntary reaction shows up. It’s been proven that just by praising the effort of an individual, chances of them choosing tougher task hence more learning is achieved. How the mistake is used by an individual whether for learning or withdrawal makes a  difference.
• The big bang approach- though some cater to this approach of changing things for once and for all, sometimes it might be difficult for an organization to go through this because of the fear of retention of employees. The sudden change can bring in the fear of transformation as to what lies ahead and why none of them are being considered allies and instead being push to do things. It’s opposite to the much formal ad gradual method that Shu-ha-ri or the Dreyfus model talks about.   

So, the transformation is a complicated phenomenon to achieve and a success deserves every bit of the celebration. 

Happy Weekend

Fish Philosophy

Last week  I spoke in Agile Tour Hyderabad, traveled for work and came back home with fever and cold.

2 days later I was happily back at office though still sick. Loving what you do is the best way to keep yourself inspired.

If you are into project management, read 6 things you should know about being one 

I think so much has been said about the fish philosophy already, there’s not really much to say about it. The core belief is perhaps the same: enjoy the work you do and be involved in it because it shows.

It’s much easier to spot people who don’t like what they do than it’s to spot people who don’t enjoy their work. And no matter what you are, unless you enjoy your work, you will find it increasingly difficult to inspire others.

Given below is a short video of the Pike Place Fish Market in Seattle, spot their energy, love of work and their unique ways to keep onlookers happy and involved.

I am back!

A lot has happened since my last post and I apologize for leaving without much notice and keeping the blog almost empty for months now.

I have reached one of my major goals and it has taken a chunk of the time. Plus work keeps me really busy along with travelling.

I have also started delivering training's and attending and presenting in seminars which takes separate time to prepare and deliver. To be honest its scary because the feedback is so immediate.

Nothing has changed much, other than trying to manage my time better and trying to fit in a lot more things. So, hopefully I will be back writing here from now on.

I hope things have been wonderful with you.

(Pic Courtesy: pinterest)

Happy Diwali!

What does project management mean to me?

Project management for me as with everyone else is all about managing projects.

Obviously how projects are managed and how you want to reach your goal depends on how you look at it.

Project management has always been a journey for me, where I have learned every single day from my work, from my team and from my mentors. It’s been more about people for me than managing work through tools.

    

    

When I started working in project management for the first time, I was part of a small service based IT organization in Chicago (US). I soon learned that people management skills were the most useful because it helped me create the connection with my clients and more trust I had from them, I could understand the expectation and always deliver more. I also knew that it also helped me work better with my offshore team, one I knew the local language and second I ensured everyone felt I was one of them. This allowed me to get to know of the real problems and not sugar coated facts when required. In return I could manage my requirement, delivery and clients better.

The way you treat your team always is the way team will treat you. When we worked under tight deadlines, team members took the initiative to stay back and get the work done. Not because they had to because they felt they were part of a bigger picture. Plus working in a small organization also means there is lesser capacity and always more work to be done. Handling situations specially tough ones, teach you a lot more because you are forced to think out of the box.

Agile project management which has gained much popularity talks so much about the transparency, efficiency, collaboration, cultivating team environments and adapting to the need- this is how I have always run my team and projects. And definitely this is the way I have learned from my mentors.

Project management for me is being successful and helping others become successful at what they are doing. It’s about understanding what makes everyone click and create amazing team dynamics where everyone grows and trusts each other.

It’s about taking the stress, so your team feels secure. It’s about creating an environment where there is lesser politics and more appreciation. It’s about supporting your team members no matter what. And it is about accepting the challenge and knowing that it won’t be easy and get up every morning and be happy to take up the role. It is about the stress, the tight schedule, the pressure to deliver, to handle problems, to be responsible, to be accountable for all failures, to work on weekends, to have sleepless nights, to smile and assure even when you are paranoid, to be there when all you want is to go home and still keep the role.

P.S. This post is published as part of a first ever project management related global blogging initiative to publish a post on a common theme at exactly the same time. Seventy four (74!) bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Netherlands, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA have committed to make a blogging contribution and the fruit of their labour is now (literally NOW) available all over the web. The complete list of all participating blogs is found here ...so please go and check them out!

(Pic Courtesy)

PM Flashblog : Sept 25

The time is set to  25/09/2013 @ 01:00GMT and posts will be tagged on social media with #pmFlashBlog. To know more read Shim Marom's post here.

On September 25, 96 PM Bloggers from all over the world will participate in a flashblog.
You can see the teaser here

So, while you enjoy your weekend, I am traveling again tonight and the stress to pack over and over again has considerably reduced.

To learn about how to get into project management read my book Stepping into Project Management (Welcome to the #PMOT World). To connect with experienced Project Manager's from all over the world, get mentored or shadow for a day see the SIPM Community.

7 Tips: When travelling for work

Travelling can be fun unless you are doing it way too much.

I still love it and the challenges it brings with it, over the past few months I have learnt the art of  packing mostly over terrible mistakes.

• Always pack in your own shampoo- The hotel shampoo might leave your hair so limp that you wished you had your own.
• Always have an extra pair of clothes in your handbag/backpack- I keep one in my laptop backpack just in case my luggage doesn't arrive. 
• Travel Light- I carried more than I should initially, now I just pack right most of the time.
• Keep a list- It helps every time.
• Be comfortable- I carry one thing with me that will make me comfortable and keep me relaxed: a magazine, iPod, a good book.
• Try local cuisine- This is my favorite part of travelling, I might not get the time to try out sight seeing always but at least I get to try the food.
• Learn everyday- There's so much to learn by just observing people or while travelling. We get used to the same set of people so much that a change while travelling gives us a better opportunity to learn when we travel.

So, while I'm leaving for the airport in the next 30 minutes- I hope you get the chance to travel and say yes to it!

How should teams be build?

When an actor comes to me and wants to discuss his character, I say, “It’s in the script.” If he says, “But what’s my motivation?” I say, “Your salary.”

                                                 —Alfred Hitchcock, filmmaker (1899–1980)

Jim Collins talks about getting the right people in the bus in his book “Good to Great”. And we all agree- but how do you decide who are the right people?

Hiring happens based on the core competency, but when you put them as part of the team, how do you know they will work out?

Does team dynamics matter to you or your organization? Do you think it changes the quality of delivery?

The common failings for any team at organization level usually comes down to:

·       Develop empowered people working together to serve the best interests of the organization, and

·       Create an environment in which every employee contributes all of their talents and skills to the success of organizational goals.

To ensure we get individual players be and feel part of the team- is there a way to create teams at the first place differently? Like do you think, if teams are created based on their compatibility or interest, they will perform better OR do you feel any team if mentored and trained in team/organization culture will perform at their highest level?

To think about creating the right team, I think we should first think why teams fail at the first place? Why do teams not perform the way they should be? Is it a bad apple? Is it lack of proper management and setting the expectations? Is it freedom without no boundaries and when things go wrong, blame the team? Here are 20 mistakes that employers make.

Are we aligning people with their interest and what they want to do or do we just not hear what they have to say and push them into any role and any teams?

The hedgehog concept talks about looking into 3 aspects before putting the right people in the right role

By considering:

• What are you passionate about?
• What can you best in the world at?
• What drives your economic engine?

This definitely brings out the best in individuals but how do we ensure the best is brought out at team levels also?  What if you got the right person in the right role and then had a bunch of laggards as team mates. Do you think we have set the right environment for him/her to grow and contribute to the best of ability?

How does your organization formulate teams? What do you fee is the right way to do it? 

(Pic Courtesy: Google Images)

Interview with Ellen Grove

We are happy to have he opportunity to interview Ellen Grove, who helps teams do better work by coaching them to create the circumstances in which they can work most productively. Her Agile coaching practice with agilepartnership.com is founded in over 15 years’ experience leading software development and implementation teams in global enterprise, a passion for exploratory software testing and user-centered design, and a background in community organization. Ellen presents frequently at Agile conferences, most recently: San Francisco Agile 2012,Agile Day NYC 2012, Agile Tour Montreal & Ottawa 2012, Play4Agile2013 (Germany) and Agile Games 2013 (Boston).  She is the Scaling Agile Adoption theme chair for Agile India 2014. 

How did you begin in agile coaching/consulting?

I got my start as an agile coach while I worked for a large telecom company. My background is as a software tester, though I've done a little bit of everything except coding along the way.  My team had begun as a startup, which had been acquired by the large company but maintained the startup mentality of doing it all ourselves and trying to get things done with a minimum of process.  The company decided that they needed to introduce a standardized process for software development across the entire company; my team looked at the proposed process and realized we'd need to double the size of the team and the length of our release cycles just to handle the process overhead, which was obviously not acceptable.  

We decided that we would need to counter-propose an approach that would demonstrate some discipline in the process yet give us the flexibility we needed to do things very quickly.  Until then, we'd been playing with some Agile ideas informally, but hadn't really made an effort to work intentionally in an Agile way.  

This is when we got serious about Agile.  After arranging for myself, my boss and his boss to attend Scrum training,  I helped to organize and deliver Agile training for all the teams involved on the project: there were three teams involved, spread over 3 countries and a 10-hour time difference, as well as an external vendor who was supplying a vital component.  We were working in 1 week iterations (integrating the work of 4 teams) and learning a lot as we went along. I was playing many roles - leading the testing function, acting as Scrum Master for one team, and serving as an internal Agile coach to the larger project team.  I was also involved with the company's process team establishing an Agile alternative to the big universal process they were trying to introduce. It was crazy, but quite a lot of fun while it lasted.

When that role ended, my next gig was as a project lead on a non-Agile global network transformation project, very complicated and complex and risk.  What I learned from that experience was that I really only wanted to work on Agile projects, since Agile approaches offer some of the simplest ways to manage risk and complexity.

In a small company with less then 200 people following Agile, do you think a project managers role is as important and would be beneficial. Why?

Interestingly, in the large telecom situation there was never much attention paid to project managers, even though we had one on our team all along (even when we were still operating as a startup).  The PM was the person who updated Gantt charts, counted things and went to boring meetings that none of the rest of us were interested in.  It was quite a surprise for me to start consulting in other organizations where the Project Manager was effectively the leader of the project.

I think that many of the functions of project management are critical, but on a smaller team/project the important elements of the function can be built into the team's work and there's often no need for a designated project manager. Where I've seen real value in a PM role is in larger organizations where the PM acts as an interface (and shield!) between the development team and other functions in the company, allowing the Scrum Master (if the team is using Scrum) to focus on supporting the team's day-to-day activities and leaving the team to coordinate its work internally.  It's often very hard for people who are accustomed to a traditional PM role to make that jump and let the team have space for self-organization. 

Tell us a little more about what you do as a LEGO Serious Play facilitator.

I love doing LEGO Serious Play - I wish I could spend all my time running LSP workshops!  LEGO Serious Play is like play therapy for business.  It's a very simple, structured process that enables people to have really important conversations about how they're working as team or to share ideas about the work they're doing in a way that is designed to help them get to the heart of the conversation very quickly.  

How an LSP session works : the facilitator asks a question, the participants build a model to answer the question in a very short period of time, and then each person at the table shares their story about the model with the others. This process is repeated a few times to build up a shared understanding of the subject at hand that incorporates the viewpoints of everyone taking part. A longer workshop may involve fitting the individual models together in an integrated landscape to really create a shared view of what the aims of the group are. 

It's simple, but incredibly powerful.  Because people are using their hands as well as their brains, unexpected ideas emerge.  Time-boxing the builds forces a focus on the most important ideas.  And seeing the ideas take shape on the table results in a different kind of understanding about how the pieces fit together.  I use LSP for everything from team building sessions at the start of a project, to strategic visioning and planning, to retrospectives.  

I've written a bit on my blog about how LEGO Serious Play works.   I tend to overuse the word "magic" to describe the results of LSP, but every single time I run a session I'm blown away by what ends up on the table.  People are often very skeptical before they've used LSP to do work because it seems silly and not serious, but once they've taken part in an LSP session they realize how incredibly powerful it is as a tool for helping people to express what's in their heads and their hearts.

When working with organizations how you do come up with a strategy?

My Agile coaching strategy is fairly simple:  1) Help the organization figure out what they're really trying to accomplish, and then 2) help them find ways to get there.   This sounds easy but usually is not, especially in larger organizations where there is often ambiguity and conflict in what the real goals actually are.  With small teams/companies, there's usually a clear set of desired outcomes driving the team ('Make customers happy so that we make money and stay in business').  With larger organizations, especially in the public sector, it's often much more complicated to understand what the actual goals and desired outcomes are. "Get the project done" is a fairly meaningless goal unless you understand what the real value to be delivered through the project is and who you're delivering to, but large public sector projects often fail to communicate either of those things to the people who are doing the implementation work - the message conveyed to the team is usually "Here's the requirements, just get it done!".  It's very hard to transition to an Agile way of working in those kinds of organizations.

What are the 3 things you would suggest to all Agile project managers? 

Focus on the value being delivered through the work, not the meeting the expectations of the plan. Inexperienced PMs sometimes lose sight of this and confuse "successful delivery of project artifacts" with "a successful project".    It doesn't matter if you deliver on time and on budget if the end result doesn't please the people it's meant for. 

Trust your team to do the right things (and tailor your behavior accordingly). People tend to live up to what's expected of them, and if you want to encourage responsibility and accountability in your colleagues, you need to treat them as responsible, accountable individuals with good intentions and good judgment. Most people want to do great work - and if they don't, taking a command-and-control approach to managing their work won't result in happiness for anyone. If they do want to do great work, a controlling approach is just going to get in their way.

Make it safe for the team to fail. If you don't want the bigger effort to be a failure, you need to help create a culture (at least within the team) where it's OK for people to make mistakes and to ask for help when they need it.  I've seen too many big problems that were caused by smaller problems being ignored or hidden because team members weren't comfortable being open when things went wrong.  I'm a big fan of the "Failure Bow", because it's so much better in the long run to handle failures well instead of blaming-and-shaming so that we can learn from mistakes.

Thank you Ellen.

(Pic Courtesy: Ellen Grove)

The Broken Glass Theory: And What You Can Do About It

The Broken Glass Theory was introduced in 1982 by social scientists in Atlantic Monthly which says if there’s a broken window in a building, chances of breaking more glasses has a higher chance than in a building with no broken glasses. 

So as project managers, the goal is simple- fix things as soon as possible lest the rest of it gets broken too.

When you look from a team perspective, the goal is to ensure if you find something broken or out of order, address it immediately by having a one on one with the team member and seeing how you can help in the process.  The problem with not fixing the problem is that it will become a bigger problem when its gets too complicated to handle it and will create a furor in the team environment.

If you see the from organization culture point of view, not resolving or looking into the issues make it evident to the rest of the team that its okay to engage in these disruptive actions and management accepts it. This definitely send a wrong signal.

Address the trouble maker immediately and send the right message to your team, to ensure the process and work culture stays in place.

However, there is another research which shows that the Broken Glass Theory doesn’t work and the theory works because of dependencies because of some other action that took place.

Whether this reduces the crime rate or not (theory comes from criminal perspective), it definitely makes sense from the team handling. Leave a team with problems and it will only grow bigger and unmanageable.  

(Pic Courtesy: Google Images)

Have a Good Weekend!

Agile Managers- what should you do?

“A leader is best when people barely know he exists. When his work is done, his aim fulfilled, they will say: We did it ourselves.”  -Lao Tzu

Simple things create the greatest impact. As Agile Managers, the goal is to ensure your team is groomed, mentored and ready to take up any challenges.

To do so, you also have to lead by example- you should be able to:

• Inspire
• Be supportive
• Be empathetic
• Be honest
• Be objective

So, your focus is always to keep the team out of crisis so they can function at their optimum velocity.  Deming in his “14 action point guide” points at how one can get anyone out of the crisis mode. If you look at them, the main things to consider would be:

• Creating constancy of purpose- it’s important during any time or during any transformation process to let your team know about the purpose and why what is happening. This avoids the most important confusion of team members being insecure, going through a loss of direction and not being comfortable with the change. 
• Improve constantly- managers role is crucial here in keeping the theme of improvement going always. If you can inspire them in a one of a kind way, it has to be by dispersing the common message that every team member collectively has to improve. You can measure improve in various ways- by seeing team velocity, by seeing quality of the deliverable, seeing the team dynamics or seeing the happiness index of teams. 
• Drive out fear- encourage people to express freely in your organization and team. Even if the feedback is negative- against the process, against the team or may be against you- it allows you to know the reality. You can only know how to respond to and what strategy to implement if you know the genuine problem. 
• Remove barriers that that rob people of their pride to workmanship- inspiration for any work when intrinsic is way more productive than when its extrinsic. If you can find out what motivates them, what keeps them going, it’s just way easier to know their intrinsic motivation. I have worked with teams, who at some point got bored with the same kind of user stories in their backlog and wanted a change. In such situations just ask what they would like to work n, or what motivated them, One team wanted to take more risks at their work because they thought otherwise it gets boring; they did risk in one of the sprints against their committed stories and still finished really well.  The team member just find it motivating enough. 
• Recognition for their efforts for some is very important- just by simply saying  a ”thank you” or recognizing them during daily stand ups is enough to keep them happy and it doesn't take a lot of time or money! This point actually came up in one of my happiness index surveys with a team and since then I have always tried to recognize members for their efforts, no matter how small they are! So, during retrospectives, we make a point that the team thanks other team members by simply writing n sticky notes about them and then we tack it in the cubicle walls. 
• Put everyone to work- because transformation is everyone’s job; especially if you have adopted agile very recently. No one should feel that their part is for granted or not important. Keeping everyone involved is the most tricky part when going through transformation. And this is something only managers can do. You can work with your Agile consultant/coach on these scenarios, however you have to make the final call.  As a manager you have to let everyone now how they can be involved, contribute actively and help management make decisions.  

(Pic courtesy: Google Images)

Scrum Gathering Pune

This post comes in a bit late I guess, mostly due to malfunctioning internet of my phone at the seminar and travelling next few days.

The Pune Scrum Gathering was bigger than I had expected, lots of people from all over the world and a location that was at grand as the event! 

The keynote speaker was someone I knew and had read his blog for years. To see Jurgen Appelo in person was nice and it was one of the best presentations in the 2 day event.

Most of my 2 days was spent with my colleagues, sometimes in the seminar, mostly just helping them out in the exhibition stall that was put up- just chatting up people who stopped by and answering different kind of questions.

By the way, I did manage to get an autograph from Jurgen Appelo, last one was from Elizabeth Harrin. I am still old fashioned that way!

The sessions have something for everyone- from real life case studies to new methodology to theories about latest way of using them in industries. So, whichever level you are in; you get to learn. Breakfast and lunch was good, so was the opportunity to network with hundreds of others and learn from them.

I enjoyed most of the sessions I could attend, some more than the others like that of Nancy Sharma.  She brought n the behavioral traits required in an agile team and unlike others she handled questions during the presentation, went back to it with aplomb and brought in amazing insights form the real world on how to encourage the team culture in an organization, how to handle loners and naysayers along with the so called heroes.

While this was my first visit to Pune, I loved the city and will return definitely. I enjoyed meeting up a friend over an Italian dinner after 10 years, meeting his wife for the first time and talking late into the night listening to stories on how they had met. The next day evening was spent with colleagues and client over an extended dinner.

Here are more pictures from the semnar in case you are interested.

Scrum Gathering Pune (India)

The next 3 days will be pretty fun. I am heading out today for the Scrum Gathering Pune and will post updates, pics and lots of chit chats in the blog.

I am looking forward to listening to some great minds including Jurgen Appelo

So, stay tuned for the latest updates via the blog and twitter (@Soma_b)

Are you bored at work?

Let’s Help Melly from Jurgen Appelo