The Read: Social Media for Project Managers

A review of the book Social Media for Project Managers by Elizabeth Harrin:

Social Media is a term used to refer to the tools and platforms that are now online to allow people to connect and collaborate.  Popular social media platforms include Twitter, Facebook, WordPress and Pinterest.  There are a lot of options for using social media, and the popular platforms come and go, but most users of social media see it as a medium that is here to stay and is in fact, the way of the future.  Social media already has a huge impact on modern life and even though it has been slow to penetrate the corporate world it has made inroads there as well.

So how can Project Managers use social media to help with managing project teams?  Is it worth exploring?  If it is useful to Project Managers, are all aspects of social media applicable?  What might be worth implementing and how do you make this change?  These are all topics that are discussed in Elizabeth Harrin’s new book Social Media for Project Managers.There are challenges to incorporating social media into the traditional workplace and a lot depends on your team and your corporate culture, as well as your own commitment to incorporating social media into your management process.

In fact, there are enough pieces to evaluate and implement, and enough change to manage, that implementing an effective social media solution to project communication is a project in and of itself.

Once you’ve done the work, the hardest part of the process is adoption.  How do you get everyone to use it?  How do you get management to understand the importance and potential of it, not only to get it started but to also give it a chance?  It is a lot of work to end up discarded and unused.

But if you can get it working and set up in a way that works for your project team, it can be great.  Imagine one place to share and collaborate that is accessible to any team member, anywhere.  One place to update and store information.  This is really the way of the future in the workplace so learning this way of working early on, it can only help you.  Besides, managing communication by e-mail is unpleasant for everyone.  Technology has given us a better way, if we can leverage it effectively.

Here are some social media technologies that you might find helpful.  Microblogging consist of short updates and messages that are much like chat but are visible to everyone.  These are great for quick updates.  An example of a microblogging tool is Twitter.  Blogs are a great way to provide more comprehensive project updates.  Instant messaging is like e-mail but happens in real time and allows you to see who is on, as well as to chat with multiple people at once.  This is handy when not all team members are on site and something can be addressed quickly.  Wiki’s allow your team to compile the teams collected knowledge in once place.  Topic entered here can link to other related knowledge and allows users to search for the topic needed instead of opening and searching through stored documents.  There are others tool as well that are covered in the book.

I think this book has helpful information in it, especially if you have little knowledge of what options are available to you.  The book also gives you fair warning of the challenges and pit falls that you can run into, especially when dealing with managers or co-workers.  The book is small and it is not a total slog however it isn’t an exciting read either, so it took me a little longer than it normally would to get through it, because I kept getting bored and putting it down.

This is a worthwhile book if you are looking for some sound ideas on how to start incorporating social media into your projects, as the author is level headed and has some good advice.  Don’t think that this book will be all you need however.  It doesn’t really help you choose specific software.  It doesn’t have any detailed help for setting up a solution that will work for you.  This book is at a high level and is really just an introduction to the possibilities and some advice on change management.  So just keep in mind that there will be a lot you have to figure out for yourself.

Schwaber Google Lecture Video – Scrum Et Al

I just watched an hour long video of a lecture given at Google by Ken Schwaber, one of the co-founders of Scrum given in 2006.  At first I was daunted by the length but Ken is an entertaining speaker and I felt that many of the points he makes are worth hearing.

Here is the video:

Ken starts from the very beginning on the Scrum framework, where the name came from, and then addresses how Scrum either works, or doesn’t given management, the team and the organizational effectiveness or culture.

Here are my notes from the video:

1) Scrum is a method developed from the experiences of those in cross-functional tight deadline competitive environments and was developed through collaboration based on a collection of best practices.

2) During Scrum employees should not be interrupted and should get any resources they need because they were working on something critical for the company.

3) The key aspects of scrum:

  • Everything is a time-box so that things don’t go on forever.
  • Everything is done with cross-functional teams that are responsible for managing themselves.  The best people who can figure out how to do the work are the people who are doing the work themselves.
  • It’s a team that has to have something done at the end of the time-box and can potentially be shipped.

4) SCRUM is used to manage product development.  SCRUM is not a methodology.  If you have a question on what to do you see if it fits in the framework.  There are not many rules but you can find detailed strategies that others have discovered works for them.  It is like chess; how you play it is up to your own intelligence, skill set, etc.  You will know right away if the project is a non-starter.

5) SCRUM frees us from the belief that someone has to tell you what to do in every situation.

6) You want transparency during Scrum.  Know exactly where you are at the end of every time-box.  Even idiots can do SCRUM they just produce crap.  You know if you have a bad team right up front.

7) The Scrum Process:

  • Start with a prioritized list of stuff that needs to be done.  Most important or highest risk etc.  This list is used for starting iterations.
  • A cross functional team of people gets together with the person representing the customer.  This team says how much they think they can do in a sprint.  (his favorite – 30 days) where done  means that the product is ready to be used for that product.
  • Then the team goes off and has a whole period with minimal interruptions.
  • At the end of the period the team shows the customer what they have done.
  • Each team member must exercise their profession competently.
  • The customer must accept the finished work.
  • The process starts again.
  • The process allows you to hone in on your target.
  • A few rules – feedback loop – deals with adapting to complex changing environments.
  • Can’t have feedback without a finished product – can’t have PowerPoint’s of what we plan on
  • Every day the team gets together and makes transparent what they are doing.  Synchronizes the team on a daily basis.
  • It has some rotten things – like finding out the person that you are counting on will not do what they are supposed to do.

8) Burn down – amount of work + estimated + ability of team to transform it into product that is ready to ship = Burndown.  A Burndown graph can predict when the product will be ready.

9) You can tell after a couple of months where the release is heading:

  • The trend can tell you early on if there is a big problem as the trend line will let you know if you are on target.
  • It gets all of the news visible whether it is good or bad.  Intelligent people will want to do the best thing for the organization.  It is a test of the character of the organization on whether they can successfully implement scrum.  Do they have the capacity to handle the news and do something about it?
  • What happens when bad news about the trajectory goes to management?  They ask you to increase your velocity.
  • The assumption is that you can always work harder or you are “not on-board”.  We have time honored conditions for increase velocity – drop quality/cut corners.  Not do unit tests and automated tests.  We can work long hours.  Scrum should have a sustainable pace.  Downtime allows an employee to work on the problem while they are not working.  Longer days increase defects.  Longer hours and cutting quality produces more crap.

10) Common problem with every organization is the lack of support for Core or Infrastructure Software.  On a Burndown chart the developer can develop quickly but the velocity of the core software is very slow.  Core software has three characteristics:  1) it is fragile – change one thing and it breaks other things 2) it doesn’t have good automated test harnesses around it so you don’t know if code changes will break things until it does 3) Only a few suckers left in the company that knows how it works and how to maintain it – everyone else fled.  This lowers the velocity of changing the infrastructure.  New stuff is constrained by the core functionality.

11) The deterioration of quality in software development:

  • If you cut quality than over about five years the velocity will decrease anyway because the code base that you are working from has deteriorated.
  • Book recommendation: The Innovator’s Dilemma
  • Management thinks that they are magic – just ask and it will get done faster.  People will automatically cut quality if they are forced to make  a choice between this and delivering late.
  • Another option is to cut (scope) functionality.  This is management’s other option.  Overall, 65% of delivered functionality is never used, .  Management will be forced to look at what they can deliver that has the most impact given the velocity rather than just giving the team a laundry list.
  • SCRUM is about managing big changes – incrementally, iteratively, through self-managing team and transparency.

12) The Scrum Master (the prick), this person’s job is to make sure that you don’t cut quality.  They have no authority.  If we have defined a certain level of quality then they have to make sure the quality is there.  If the quality isn’t there than you cannot demonstrate it.  They are the least loved person in the world because they stand right at the nexus of product management believing that any amount of stuff can be done and our willingness to cut quality to help them support that belief.  The burnout rate is usually like, 13-14 months.  We get them from hopeless professional areas like QA.  People from QA are used to doing incredible things with no authority, no respect, and no hope of success.  So that is where we take these people. (He is joking here but also serious about QA people making good Scrum Masters).

The Read: The Power of Scrum

In my previous post, “The Scrum Master”, I spoke about how the Scrum Master recommended the book “The Power of Scrum” by Jeff Sutherland as a must read for anyone that needs an introduction to Scrum.  That same day I purchased the book and the Scum Master was correct, it was an easy and absorbing read, and I finished it that same night.

The book is written as a story, almost a novel in form, about a CTO whose software development project is still not done after going over schedule twice.  His clients are ready to fire his company and he just barely manages to get a final three-month extension.

The story quick moves on to him meeting a Scrum consultant in a bar and than follows the process of the CTO transforming his traditionally managed software development team into an Agile team using Scrum.

The book format manages to both be engaging and informative because the story format is compelling and easy to envision, but there is also a summary section at the end of each chapter starting in chapter two, that outlines the key learning points from the chapter.

There are a lot of summary points, but you only realize it once you are done.  They never seem overwhelming in the context of the book.  I cannot outline all of these points but here are a few key ones for me as I either hadn’t picked them up in other reading or they clarified details I was fuzzy one:

1.  (#4 Pg 17) Scrum supports a development team by becoming completely flexible regarding the work in the next spring.  In return the team needs to be completely inflexible regarding the work in the current spring, thus guaranteeing  that they complete each Sprint.

2. (#8 Pg 17) It is the customer’s responsibility to make the developers understand what is needed.  That requires frequent and intense contact.  If a customer is not willing to make such and investment, then the project apparently does not add enough value for them to take it seriously.

3. (#3 Pg 28) The scrum team should be seven people, plus or minus two.

4. (#2 Pg 41) Using Scrum, the product is always ready.  You are able to deliver a version of your product that is at most one Sprint old.

Another development that I found interesting was that the traditional Project Manager in the story had to take on a new role and had to abandon all of the traditional project management tools.  The project was driven by the team members performing the work.  The argument against traditional project management tools was that the planning process drove the project rather than communication with the customer and that there was an avoidance of true communication because it might jeopardize the carefully crafted project plan and create more work for the Project Manager.  The PM was turned into the Product Owner.  He was responsible for understanding the customers needs and wants and then for transforming them into the stories in the Product Backlog.

Overall, I got a lot out of this book and I would recommend it.  I would like it if the other members of my team read it too, but if nothing else I feel that I can begin to explain the process.

Here is a little bio on Jeff Sutherland from QCon:

Jeff Sutherland, Scrum co-founder

 Jeff  Sutherland, Scrum co-founderDr. Sutherland is a Certified ScrumMaster Practitioner and the inventor of the Scrum development process. He has been VP of Engineering and/or CTO for 9 software product companies, developing Scrum in 4 of them and introducing today’s standard Scrum methodology to 5 of them.As CTO of PatientKeeper and IDX, he used Scrum to capture industry leadership for mobile/wireless/web application platforms in healthcare, enabling physicians to enhance revenue, reduce cost, and improve patient care. Recently, he has evolved automated Scrum tools for real-time management reporting, while reducing Scrum project manager overhead to 10 minutes a day and developer administrative overhead to 1 minute a day. This is an order of magnitude more efficient than traditional approaches to project management.In recent months, Dr. Sutherland has been a Scrum consultant to Microsoft, Yahoo, Ariba, Cadence, Adobe, GE Healthcare, and M3 Media Services bringing PatientKeeper Scrum practices to the broader software industry.

Any other thoughts on the book?  Any Project Managers out there who disagree with the way the Project Manager of the piece is portrayed?

The Scrum Master

A Scrum Master is responsible for facilitating the daily stand-up meeting in Scrum and for removing any impediments that come up to block progress on the project.  The Scrum Master where I work has not been one for long, yet he is a pioneer for the Scrum method of Agile at my workplace.  He has a sharp wit and a lot of experience with IT projects.

Even though the Scrum Master is new to Agile and Scrum he has done a good job of educating himself on the principles, and more importantly, he has done a good job of putting them into practice.

When I asked him if he could talk to me about what he was doing during the Scrum process he agreed to show me.  I could immediately tell that Scrum had really caught his interest.  He showed me the Scrum board where there were a spattering of post-its in the various to be done, in progress and completed columns.  One thing that his group does a little differently is that they have a testing preparation column.  This ensures that there is a way to test the change as it is being developed and directly after.  He also showed me the software version of a Scrum board.  His group is trying out a free online software program called Scrumdo.

I found the time enlightening and I wanted to know more so he recommended the book, “The Power of Scrum” by Jeff Sutherland.  He told me that if I really wanted to get a feel for what Scrum is all about in practice, I should pick up the book and read it.  He assured me that it is a quick and entertaining read and that it should not take me more than a couple of hours to read.

So, meeting with the Scrum Master was very helpful.  I will pick up the book and let you know how it is in my next post.

Are  you a Scrum Master or do you work with one?  Please tell me about it in the comment section.

Exploring Agile – Scrum in 8 Minutes

As I explained in a previous post, I have been tasked with learning what I can about Agile project management for a small project I have coming up.  The first thing I did was ask a senior Business Systems Analyst about how her foray into the Agile process was going.  She in turn sent me the link to a couple of videos on You Tube as an introduction to the Scrum process.

The first video is only eight minutes long, thus it’s title “Introduction to Scrum in just 8 Minutes”.  The two presenters are Arif Gangji, the founder of Neon Rain Interactive and the founder of Agile for All, Bob Hartman.

The second video is an hour long and goes into considerably more depth on the topic, but I will save that for a later post.

As I started this video it was immediately apparent why the BI group had chosen it. Although it is short, it does do a reasonably good job of covering the basics of the method in a concise and clear manner.

The video sticks to the basics of the Scrum Framework.  Here are a few of the main points covered in the video:

  • The process starts with the product owner creating a prioritized, from most to least important, product backlog. A backlog is comprised of stories – who, what, why – that are the dreams and wishes of the customer in story form.
  • The team uses the product backlog to determine how much work can be done in a sprint.  The team should never commit to more work than they can deliver in a sprint with a sprint lasting between a week and a month.
  • The speed at which a team can deliver work is their velocity.
  • A team takes on the work in a sprint that delivers the most value to the customer so that the customer delivers the most value as early as possible.
  • Each day there is a daily Standup Meeting or “Scrum” Meeting that lasts for 15 minutes or less. During this meeting the following is accomplished:
    1. Talk about what has been completed.
    2. Talk about what they intend to complete
    3. Talk about any impediments that may be preventing work from getting done.
    4. The team uses this time to determine how to best share information to best help each other to meet their sprint commitment.
    5. This exposes risk and knowledge to be shared to help the team be more effective
  • Scrum requires there to be a Scrum Master who helps to ensure success by helping to remove impediments, aiding in making decisions and to support the team in any way possible. This role is vital for team to be successful.

This video was a good start for me, and I hope that you will find it helpful as well.  Do you know of any good Agile related videos or books that helped you to get up to speed on Agile?

Exploring Agile at Work – The Beginning

Agile is quite the buzz word in the project world right now.  Everyone is trying it, everyone wants to be doing the new thing.  I’m not sure the Agile project methodology is really all the new anymore, but it certainly is where I work.

My fellow analysts are one by one being sucked into a whole different world of working on project teams, and now it is my turn.  I’ve been fascinated with the concept of Agile methodology for awhile now but had never been exposed to the real thing.  Most of what I have read on the subject has been heavy on the theory and the glory but light on the details of how it actually works.

There are many consultants promising magical results for very hefty fees.  They say they will come in and transform your business for you.  I hate to be so cynical about this trend but knowing how to adapt a practice to a unique and complex corporate entity with its unique culture is a daunting task, and I can’t imagine that it is always a successful one for those coming from outside and promising transformations.  While I have worked with some consultant that are very good, most have left something to be desired and can do as much damage as good when trying to push big change too fast.

For this reason I am relieved that where I work we have decided to take on discovering Agile for ourselves.  Our Business Intelligence team is doing a great job transforming into an Agile team and they are seeing results even though they have not been using the process very long.  We are taking it slow and letting the adoption of the process grow organically starting with smaller projects.

I’m sure that as with most popular trends that there are some fanatical proponents of Agile dogma that may not think that we have ‘perfect’ Agile.  One recent blog post on PM Hut, “Post-Agile?” addressees the growing complaints that large organizations aren’t doing real Agile.  I can understand that there may be disappointment with some expressions of Agile, when it doesn’t result in the perfectly imagined workplace that descriptions of Agile have caused many to dream of. It is hard for me to view the fact that Agile hasn’t stayed ‘pure’ as a problem though because I think that with any new idea there is an inevitable evolution and the heart of evolution is that each ecosystem exerts pressures on those that live in it to create an end form that is most adaptive for that environment.

With that in mind I am excited that my co-workers are finding success and delivering results to our company.  I’m also excited that I will get to be a part of this evolution whatever form it may take.  As I learn more about Agile I will post more about my experience, and hopefully I will hear from others who have worked with Agile as well.

Have you explored Agile in your workplace?  If you have I’d love to hear how you got started and how it has worked for you, so please tell me in the comment section below.