Will Power and free resources for wannabe Project Managers

You never know where inspiration comes from

.

I have been doing random stuff to keep myself going and one of it has been watching youtube videos. I recently watched a TED talk by Kelly Mcgonigal and that led to watching more talks by her. This one is my favorite.

It talk about Will power and what we can do to attain it and how smaller interventions actually change the way we think.

I also read up her “how I work” series in LIfehacker  as it seems very natural to see how she does it in real life. I hope this video gives you the will power you need to pick up or face a storm in your own work space or life .

 By the way if you haven’t noticed, there’s a new e-book in town by Geoff Crane where he has gotten 52 project managers from all over the world talk about their initial experience into the work life and profession. Its insightful and a must read for all including seasoned players- there’s something in it for everybody. And am more than honored to be part of his project. 

52 Tips to Break Into Project Management from Geoff Crane

 

Leadership

Pic Courtesy: Pinterest

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.