Search

The Personal Agile Transformation: An Agile Journey To Productivity

Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business value compelling. However, whenever one reads about this transformation, it’s usually from the perspective of the organization and how Agile impacts it as a whole.  But while from the outside it would appear that an organization is some faceless monolithic structure, we know that it is comprised of living, breathing people who themselves deliver the goods and services that the organization provides. And so, it seems important to consider what the impact is on those who must deal with their own personal Agile transformation.  I have been performing traditional project management for over twenty years. I teach project management as well, and I’ve always been fond of telling my students that project management is, like accounting, a mature profession. Accountants talk about debits and credits and the only thing that really changes periodically is the tax code. The lingua franca of project management is, and for many years has been, artifacts such as Gantt charts and Work Breakdown Structures.  But to a great extent, the ground has started to shift under the feet of traditional (plan-driven or waterfall) project managers, especially in the last few years. This is because the Agile approach, initially defined in a manifesto in 2001, has really begun to establish itself in corporations. Not, I would say, to the extent that it is replacing traditional methods and not everywhere.  But significantly enough that project managers now need to be not only conversant in it but must also begin to consider being trained in it and getting some experience. (Its greater recognition in that bastion of traditional project management, PMI’s Project Management Body of Knowledge, Sixth Edition, is a fairly significant development).  On a personal level, I got my Certified Scrum Master certification in early 2013 but never used it, at least not initially. It wasn’t so much that I was opposed to Scrum as much as that I was working in traditional project management and hadn’t really witnessed first-hand the revolution under my own feet.  But gradually I began to realize that there was going to be a significant shift in the direction of the use of Agile and that in order to stay conversant – and, I might add employed – it would be necessary to start getting exposed to Agile projects and working in them. And in thinking about it, I realized that perhaps the very first thing I had to contend with in Agile was the fact that not only is the project manager role not quite as significant, in fact, there is no defined PM role as such. In the Scrum variant, there are only three defined roles – Scrum Master, Product Owner, and Development Team. When I got my Scrum certification, I realized even then that it was a different type of role. As a project manager, I might – and should – do all the planning with my team. But when it comes time to decide who did what and when, that was always my job. It is very much of a command and control structure. And not only did I expect to lead the team, the team expected to be led. But in Agile it’s quite different. In that role, I am much more of a facilitator or coach than I am a driver of the team. The team is self-organizing, meaning that while I can help remove impediments for them, it is not my job to tell them what to do as such. It is their job to figure out what to do as a team and for the Scrum Master to facilitate and coach. Find some useful tips on how to succeed with your Agile transformation below- This is a major shift, not only for the project manager but also for the team. For the project manager, he or she must stop being directive and start being facilitative. For a lot of PMs, this is a very challenging transition. They don’t know how not to direct. And as likely as not, if they have been a PM for a long time, they are very much used to using a scheduler such as MS Project. But a Scrum team doesn’t necessarily need such a tool, preferring workflow tools such as Jira to track progress. The challenge is that the traditional project manager must hold back on telling the team what to do when they ask. He or she can remove impediments when they arise. But his or her best advice when asked what a team member should do is “take it to the team.” In a sense, he or she has to rethink what he knows and throw some of his or her training out the window.  Be a Scrum Master, Not a Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK — Seth G. (@Nicko_iCorplife) October 14, 2017 And it isn’t just the PM that may have a problem adapting to this new reality. Imagine the team member who is used to being told what to do in a hierarchical situation. Now he or she is faced with, to a certain extent, being self-directed. Some prefer not to go through this experience.  And while Agile can be used for a variety of projects, it still tends to be heavily used in software development environments. And some developers, for example, used to working alone, are now expected to meet every day not only with the team but with the business. For some, this is outside their comfort zone. I spoke to a woman at an Agile conference who advised me that several developers on her team asked to be moved or left the company when Agile came in. I think the main takeaway here is embracing change and adapting. (Ironically, hallmarks of Agile itself.) Some people just prefer to do things the way they’ve always done them. And then when change overtakes them – as surely it is doing in an Agile world – they are unable to make an adjustment and wind up on the outside looking in.  Once I realized that I needed to get into this world, I made this transition not only by getting trained but by adopting an Agile mindset. (Which is what Agile coaches help teams do.) I started reading everything I could get my hands on, networked as much as I could and then when the time came, leveraged that knowledge and my years in project management into a role within a company that, while Agile-ready, still saw the value of both approaches. And when I let go of the need to be in control – and realized I needed to be a coach and facilitator -  I found that things just fell into place.
Rated 4.0/5 based on 22 customer reviews
The Personal Agile Transformation: An Agile Journey To Productivity 157
The Personal Agile Transformation: An Agile Journey To Productivity

Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business value compelling. However, whenever one reads about this transformation, it’s usually from the perspective of the organization and how Agile impacts it as a whole. 

But while from the outside it would appear that an organization is some faceless monolithic structure, we know that it is comprised of living, breathing people who themselves deliver the goods and services that the organization provides. And so, it seems important to consider what the impact is on those who must deal with their own personal Agile transformation. 

I have been performing traditional project management for over twenty years. I teach project management as well, and I’ve always been fond of telling my students that project management is, like accounting, a mature profession. Accountants talk about debits and credits and the only thing that really changes periodically is the tax code. The lingua franca of project management is, and for many years has been, artifacts such as Gantt charts and Work Breakdown Structures. 


But to a great extent, the ground has started to shift under the feet of traditional (plan-driven or waterfall) project managers, especially in the last few years. This is because the Agile approach, initially defined in a manifesto in 2001, has really begun to establish itself in corporations. Not, I would say, to the extent that it is replacing traditional methods and not everywhere. 

But significantly enough that project managers now need to be not only conversant in it but must also begin to consider being trained in it and getting some experience. (Its greater recognition in that bastion of traditional project management, PMI’s Project Management Body of Knowledge, Sixth Edition, is a fairly significant development). 

On a personal level, I got my Certified Scrum Master certification in early 2013 but never used it, at least not initially. It wasn’t so much that I was opposed to Scrum as much as that I was working in traditional project management and hadn’t really witnessed first-hand the revolution under my own feet. 

But gradually I began to realize that there was going to be a significant shift in the direction of the use of Agile and that in order to stay conversant – and, I might add employed – it would be necessary to start getting exposed to Agile projects and working in them.



And in thinking about it, I realized that perhaps the very first thing I had to contend with in Agile was the fact that not only is the project manager role not quite as significant, in fact, there is no defined PM role as such. In the Scrum variant, there are only three defined roles – Scrum Master, Product Owner, and Development Team.

When I got my Scrum certification, I realized even then that it was a different type of role. As a project manager, I might – and should – do all the planning with my team. But when it comes time to decide who did what and when, that was always my job. It is very much of a command and control structure. And not only did I expect to lead the team, the team expected to be led.

But in Agile it’s quite different. In that role, I am much more of a facilitator or coach than I am a driver of the team. The team is self-organizing, meaning that while I can help remove impediments for them, it is not my job to tell them what to do as such. It is their job to figure out what to do as a team and for the Scrum Master to facilitate and coach.

Find some useful tips on how to succeed with your Agile transformation below-



This is a major shift, not only for the project manager but also for the team. For the project manager, he or she must stop being directive and start being facilitative. For a lot of PMs, this is a very challenging transition. They don’t know how not to direct. And as likely as not, if they have been a PM for a long time, they are very much used to using a scheduler such as MS Project. But a Scrum team doesn’t necessarily need such a tool, preferring workflow tools such as Jira to track progress.

The challenge is that the traditional project manager must hold back on telling the team what to do when they ask. He or she can remove impediments when they arise. But his or her best advice when asked what a team member should do is “take it to the team.” In a sense, he or she has to rethink what he knows and throw some of his or her training out the window. 

And it isn’t just the PM that may have a problem adapting to this new reality. Imagine the team member who is used to being told what to do in a hierarchical situation. Now he or she is faced with, to a certain extent, being self-directed. Some prefer not to go through this experience. 

And while Agile can be used for a variety of projects, it still tends to be heavily used in software development environments. And some developers, for example, used to working alone, are now expected to meet every day not only with the team but with the business. For some, this is outside their comfort zone. I spoke to a woman at an Agile conference who advised me that several developers on her team asked to be moved or left the company when Agile came in.

I think the main takeaway here is embracing change and adapting. (Ironically, hallmarks of Agile itself.) Some people just prefer to do things the way they’ve always done them. And then when change overtakes them – as surely it is doing in an Agile world – they are unable to make an adjustment and wind up on the outside looking in. 

Once I realized that I needed to get into this world, I made this transition not only by getting trained but by adopting an Agile mindset. (Which is what Agile coaches help teams do.) I started reading everything I could get my hands on, networked as much as I could and then when the time came, leveraged that knowledge and my years in project management into a role within a company that, while Agile-ready, still saw the value of both approaches. And when I let go of the need to be in control – and realized I needed to be a coach and facilitator -  I found that things just fell into place.

Jim

Jim Stewart

Blog author

Since 2003, as a principal of JP Stewart Associates, Jim has been engaged in multiple endeavors including consulting, training and mentoring. A PMP since 2001 and Certified Scrum Master since 2013, he provides PMP Prep training both in public and private in-house sessions. In consulting, he frequently contributes by helping organizations increase their project maturity. He recently consulted to a financial services firm to help them set up a project management office. Jim is on the PM advisory board of MindEdge, Inc. and is co-author of the upcoming book, “Facilitating Project Planning Meetings: A Practical Guide to Ensuring Project Success.”

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

How To Build A Self-Organizing Team As A Scrum Master

The key element of implementing Scrum successfully in an Agile-oriented business is the self-organized team; however, it leads to a misconception that every team member will be loose cannon, working without the ownership and directions for the assigned task; which is just opposite to the actual experience because the self-organized team members work together under the agreed framework of norms, guidelines, and expectations to achieve iteration goal. Most Agile-Scrum organizations emphasize on building the self-organizing team - why?  The 4 Key Benefits of Scrum Self-Organizing Team:   “Individuals in an empowered organization have the knowledge, skill, desire and opportunity to personally succeed in a way that leads towards collective success" (Stephen R. Covey, Principle-centered Leadership). The 4 key benefits that drive the experienced Scrum Master to build the self-organizing team are:  Motivation improves the performance of the Scrum team Innovative & creative environment is conducive to everyone’s growth Everyone learns from the failures and successes to perform the best with self-optimization Improves ownership because each member feels more responsible for the sprint result   Roadmap to Build a Self-organizing team as a Scrum Master:  Who is responsible for building the self-organizing team? Definitely, Scrum Master is primarily responsible for building a self-organizing team ensuring the cohesive working environment for all the team members. Like the job itself, building Scrum self-organizing team is also a complex challenge for the Scrum Masters. The complete task can be simplified by dividing it into three steps:   Step 1. Training:  The problems can’t be solved with same level thoughts that create them; and, we need the motivated trained minds with a zeal to solve the particular problems. Each Scrum team member is expected to have the best level skill set; therefore, Scrum Master must provide classroom or on-the-site task-specific training to individuals. Often, the efficient Scrum masters tend to lead to problem-solving; but instead of solving the problems yourself, it is better to let the trained team members do it. In parallel, behavioural - communication training must be planned to shorten the training period.  Certified Scrum Masters have mostly proved their potential in building such trained teams.  Step 2. Coaching:  Scrum Master must behave as a coach to guide the team members for solving the problems. Some team members may require more guidance at the start but analytical support trains them to crack the nut on their own. After proper Scrum training and coaching, you will experience the team heading for self-organizing but the task is not completed yet. Scrum Master is expected to observe the team members to make further improvements in identified areas.  Step 3. Mentoring: Keeping your team self-organizing is also a challenge because changing the traditional work habits is not so easy. The challenge can be easily managed by behaving like a mentor who helps the team members to perform at the next level. As per Scrum guidelines, the most efficient and capable Scrum team member to solve a specific problem is the one who needs to solve it. The mantra of building a successful Scrum self-organizing team is – “Self-organizing team need task oriented coaching & personalized mentoring not the “command & control”. Conclusion with 7 Tips for the Scrum Masters to Build Self-Organizing Team:  It takes time to make the people willing to take bigger responsibilities. I always say to Scrum self-organizing team members that they should take initiatives on their own instead of waiting for others to take action for problem-solving. This approach of Scrum self-organizing team speeds up the development besides providing more time for the Scrum Master to focus on other important issues. To conclude, I summarize the 7 points to help you build efficient and successful Scrum self-organizing teams:    To touch the extremes of your career as an efficient Scrum Master be honest in “Know your stuff & learn that you don’t” approach.   Assert the influence but without taking over. Suggest new ideas to address impediments; and, authorize the team members to manage the problem in their own way.  Ask complex questions to motivate the members to come up with innovative concepts Support the team members to take actions  Use safe-to-fail tests to let the team members imply learned skills Be available for the team members to let them work in a flow  Be a practical hardliner because your Scrum team needs it  
Rated 4.0/5 based on 20 customer reviews
How To Build A Self-Organizing Team As A Scrum Mas...

The key element of implementing Scrum successfully in an Agile-oriente... Read More

Difference Between Agile and Scrum

Agile describes a set of guiding principles that uses iterative approach for software development, while Scrum is a specific set of rules that are to be followed while practicing the Agile software development. Agile Agile management represents various o software-development methodologies that have been influenced by iterative and incremental development, which includes Extreme Programming (XP), Rational Unified Process (RUP), Scrum, and others. Agile process or methods provide an environment where there is constant evolution in requirements and evolution as a result of collaboration between self-organising cross-functional teams. Agile methodologies foster a disciplined project-management approach that encourages a set of best practices, allowing a rapid delivery of high-quality software and enhancing a business approach, which aligns development with the customer needs. The Agile methodologies stand in contrast to the traditional waterfall methodology, where all the requirements are initially analysed and documented before the development begins. While in Agile approach, requirements are like the actual software-development advances within each iteration. This approach provides flexibility in accommodating changes in the requirements and priorities of the business. The Agile development process aligns with the concepts of Agile Manifesto. Also known as Manifesto for Agile Software Development, the Agile Manifesto is a formal declaration of 4 key values and 12 principles supporting an iterative approach to software development. The Agile development methodology enables assessment of project direction throughout the development lifecycle. This is achieved through regular iterations, and when revaluation is done at every iteration, it greatly reduces the development costs and time. Agile helps the companies to build the right product. Benefits of Agile include as follows: • Benefits the Customers In the traditional waterfall model, the high-value features are developed and delivered in longer cycles compared to the Agile approach, which enables delivery within short cycles. This enables the vendors to be more responsive to the development requests of the customers. • Benefits the Vendors Adopting Agile benefits the vendors by having an improved customer satisfaction and customer retention, leading to more customer contacts through positive references. The Agile allows the vendor’s focus to be on the development effort of high-value features, decrease the overheads, and improve efficiency. • Quality With Agile development, there is a regular inspection of the working product, with testing integrated at every iteration, as it develops throughout the lifecycle. This in turn retains the quality of the product and also allows the product owner to make necessary adjustments whenever a quality issue arises. • Visibility Agile methodology is a collaborative approach that encourages active user participation throughout the product development. This gives an exceptional and clear visibility of the project’s progress and product development to the stakeholders. • Cost Control Agile development process has fixed timescale where the requirements emerge and evolve as the project progresses and the product is developed. This enables a fixed budget. • Risk Management In Agile methodology, small incremental releases are made visible to the product owner throughout the development cycle, which helps identify issues at an early stage, and it makes easier to respond to change, if any. Agile development ensures clear visibility, which allows necessary decisions to be taken at the earliest possible opportunity. Scrum Scrum, on the other hand, is a subset of Agile. A Scrum is a simple and flexible Agile methodology for software development. The Scrum is not a technique or a process but a lightweight and simple framework to address complex problems of a project and deliver a high-value product creatively. The major distinguishing attributes of Scrum are as follows: • Simplicity The development in Scrum is done in sprints, which are 1, 2, and 3 weeks in length. The Scrum team consists of: 1. Product Owner: The major responsibility of the product owner is to maximize the value of the product and work of the development team. Additional duties include managing the product catalogue. 2. Scrum Master: The development team consists of self-organising professionals who turn the product catalogue into product increment at the end of each sprint. 3. Development Team: The Scrum Masters make sure that the Scrum team is abiding by the Scrum theory and its rules. • Flexibility In the traditional waterfall model, when the business and technical requirements are documented and detailed, it results in endless documentation. The Scrum makes use of user stories to describe the functions needed to be developed. A tool called Pivotal Tracker is used to store these user stories in a backlog. If a change needs to be made or a need arises to add to the user stories, in that case the team can adjust as early as the next sprint. This allows the business to change their minds and the development team to be flexible enough to adjust to those changes. The ability to accommodate change is a powerful attribute of the Scrum methodology. • Communication and Collaboration In Scrum methodology, the communication between business users takes place on a daily/weekly basis according to the sprint schedule. This close communication and collaboration is a crucial factor, promoting the success of the Scrum methodology. The Scrum team achieves collaboration in following ways: 1. The Product Owner, the Scrum Master, and the development team work closely on a daily basis. 2. Sprint-planning meetings are conducted, which allows the development team to organise its work based on the knowledge gathered from the business priorities. 3. Conducting daily scrum meetings where the development team can account for the work completed, its future prospects, and deal with issues if any. 4. Conducting sprint reviews allows the team members to evaluate their former work by recommending better practices with every sprint. There are more details on Agile & scum differences
Rated 4.0/5 based on 20 customer reviews
Difference Between Agile and Scrum

Agile describes a set of guiding principles that uses iterative approa... Read More

Scrum Master and Product Owner: Understanding the differences

 Agile methodology imparts the easy and convenient path to work. Scrum is one of the famous Agile methodologies. Agile methodologies consists of 4 main roles, viz. Product Owner, Scrum Master, Scrum team and Stakeholder. Each role has its share of responsibilities. These roles are all about commitment. Scrum master and the Product owner are two vital roles in the Scrum Software Development Methodology. Since they both are working on different areas of the project, they are indispensable for the project. Scrum Master is a mediator between the Product owner and the Development Team.   Product Owner vs Scrum Master- Though the Product Owner and the Scrum master vary in their roles, they complement each other. Scrum master should support the product Owner in every step possible. There should be an amicable relationship between the Product owner and the Scrum master. Disputes may happen between them if the roles are not clarified. Let us have a look at the differences in roles between the product owner and the scrum master. The Scrum Master concentrates on the project success, by assisting the product owner and the team in using the right process for creating a successful target and establishing the Agile principles.  Scrum Master Skills (SM): SM creates a friendly environment for the team for Agile development. SM improves the quality of the product. Certified Scrum Master Certification, adds advantage to become effective. SM protects his team from any kind of distraction and allows them to stay tuned. SM helps product owner to maximize ROI (return on investment) to meet the objectives. SM removes disputes between the product owner and the development team. SM encourages the team to meet the project deadline. SM acts like a coach for a team to perform better. A good Scrum Master should possess the skills like project management, engineering, designing, testing background and disciplines. SM provides continuous guidance to teams Duties of Scrum Master: SM facilitates team for better vision and always tries to improve the efficiency of the teams. SM manages Scrum processes in Agile methodology. SM removes impediments for the Scrum team. SM arranges daily quick stand-up meetings to ensure proper use of processes. SM helps product owner to prepare good product backlog and sets it for the next sprint. Conducting retrospective meetings. SM organizes and facilitates the sprint planning meeting. The Product Owner’s responsibility is to focus on the product success, to build a product which works better for the users and the customers and to create a product which meets business requirements. The product owner can interact with the users and customers, stakeholders, the development team and the scrum master. Product Owner Skills (PO): PO should have an idea about the business value of the product and the customers’ demands. Certified Scrum Product Owner Certification (CSPO) will be beneficial for the sales team. The development team consults PO, so he should always be available for them to implement the features correctly. PO should understand the program from the end-user point of view. Marketing is discussed on the sales level in most of the Organizations. So it is the PO’s duty to guide the marketing persons to achieve the goals successfully. PO is responsible for the product and the ways to flourish a business. PO has to focus for the proper production and ROI as well. PO should be able to solve the problems, completing trade-off analysis and making decisions about business deliverables. After CSPO course, PO can work with the project managers and the technical leads to prioritize the scope for product development. Sometimes PO and the Customers are same, sometimes Customers are thousands or millions of people. Duties of the Product Owner: PO has to attend the daily sprint planning meetings. PO prioritizes the product features, so the development team can clearly understand them. PO decides the deadlines for the project. PO determines the release date and contents. PO manages and creates the product backlog for implementation, which is nothing but the prioritized backlog of user stories. PO defines user stories to the development team. Spending some time to prioritize the user stories with few team members. One can enhance his/her knowledge in many directions and beyond boundaries, after undergoing the Certified Scrum Product Owner (CSPO) training.
Rated 4.0/5 based on 1 customer reviews
Scrum Master and Product Owner: Understanding the ...

 Agile methodology imparts the easy and convenient path to work. Scru... Read More