The Personal Agile Transformation: An Agile Journey To Productivity
By Jim Stewart
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.
based on 22 customer reviews
Is Enterprise Architecture Relevant To Agile?
By KnowledgeHut Editor
Competitive people usually adopt new working ways for their organizations to stay afloat with the evolving technology landscape. Agile is one of the working ways which has been befriended by a lot of the organizations. It is capable of resolving various issues that software development has been facing for a number of years.
The role of Architecture in the Agile context has been a debate issue for decades, where supporters of an Agile points architecture as a “Big Design Up Front” which is a contradiction to the Agile philosophy. In the meantime, Enterprise Architecture has improved itself as a vital tool for translating strategy to operations. So are these two approaches conflicting each other or can you accept them together?
To arrive at a conclusion over this point, you need to understand the concept of the Agile and the Enterprise Architecture, which is as follows:
Enterprise Architecture (EA)–
Enterprise Architecture provides an insight into the various interrelated aspects in an enterprise. EA translates strategy to concepts, principles and models that provide vision to future and guide to design and development. EA provides a general review and the direction and considers the developed system as a black box system. Solution Architecture opens the black box and describes the structure and the decisions in the box. TOGAF and ArchiMate are the important standards of an enterprise architecture.
Agile is the software development technique comes under the Agile Manifesto. Agile focuses on the individuals and interactions, working software, customer collaboration and on those who are responding to change. The manifesto provides a set of principles providing tangible guidance. One of the principles is “Simplicity –the art of maximizing the amount of work not done — is essential”. The most popularly used Agile method is Scrum, considered as the simplest method to instantiate Agile.
Following are the insights over the Agile and the Enterprise Architecture to decide whether they can be blended together or not.
Insight #1: Pre-condition can be stated as Enterprise Architecture
The first important insight is that EA is valuable to determine the future of pivotal Agile projects. It provides better vision to realize, identify the application and projects which are needed to support this vision. In EA, applications can be introduced as a black box. The Agile Project can open this black box. Agile projects can refine the high-level business requirements into the epics and the user stories in EA.
Insight #2: Agile needs other Scaling mechanisms
Another important insight is that the focus of Agile will only be the teams, and not the enterprise. Dean Leffingwell designed the Scaled Agile Framework for small teams and it does not scale to the enterprise level. Enterprise Architects are also working under this framework. The responsibilities of the enterprise architect constitute of maintaining the goals, facilitating reuse of emerging solutions, knowledge and patterns.
Insight #3: Agile, SCRUM can be successful Enterprise Architecture
Finally, Agile and Scrum can be considered as enterprise architecture. They can be illustrated in the form of principles and models, core elements of architecture. This insight is for Agile proponents to convince them how Enterprise Architecture (EA)
really works. It also reveals how you can handle an EA in an Agile environment. Similarly, it shows in which project, you should handle the Agile principles and Scrum concepts. Basically, it works earnestly if carried out seriously but at the same time can be risky to adopt it if it doesn’t fit in your organization.
Insight #4: Enterprise Architects should assist to maximize the “Not Done” work
There are lots of misunderstanding related to the enterprise architects. A general misconception or you can say pitfall about the enterprise architects is that they think solely about the thing which is less prioritized. This behaviour accounted for contradiction in the enterprises. Enterprise architects should do work collaboratively with others, concentrating on “the most prioritized matters”.
Similarly, Agile teams work together, discussing each and every matter and maximizing the “not done” work. Soft skilled work is more important for every team member. Best practices like multi-disciplinary teams, collaboration, co-acts and communication should be applied in each and every organization. Thus EA should work according to the Agile manifesto.
These are the ways in which Enterprise Architecture not only performs, but does so well enough, if integrated with Agile principles.
based on 20 customer reviews
Challenges & Solutions of Outsourcing the Contracts in Agile
By Shubhranshu Agarwal
While contracting for Agile development, both the parties agree on the scope & vision at the outset but the project is developed iteratively. The traditional contracting practice seeks to agree with “what” & “how” about the project but Agile contract agrees just with “what” leaving the “how” to be managed at the development stage by both the parties. The traditional contracting approach is focused on collaborative working rather than procedural working; this philosophy encourages going ahead with a flexible & innovative approach to software development. Still, in most cases, buttoned-up Agile contracting approach doesn’t work up to the satisfaction level. So, what are the most experienced challenges and the time-tested solutions to overcome the hurdles in outsourcing the Agile contracts?
Challenges of Outsourcing the Contracts in Agile:
Signing the ‘Time-&-Materials’ contracts for Agile software development is the most used practice, but it has some serious flaws also that create complex challenges for the buyer (outsourcing vendor) and seller (client) both:
In most cases, contract is awarded to the seller who takes full ownership with responsibility for managing all the risks. The seller executes the project with outsourced human resources in ‘Time & Material’ (T&M) model.
The client owns and manages the project; therefore, the client hires the high number of IT professionals that results in unexpected and unaccounted increase in operational cost.
The buyer has very little scope to add more values at different stages of project development despite feeling capable of delivering more.
To sustain the estimated profit ratio, the project managers at client’s side overburden the buyer with more work superimposing new stories; it results in low-quality & delayed software development.
The pressure to complete the project with estimated profit ratio despite several changes in workflow and scope wears down the outsourcing vendor; thus, damaging the project development and quality.
Under Agile environment, it is expected that as the knowledge level of engaged Agile team members increases with the passage of time, they should deliver more with enhanced velocity; this approach doesn’t take into account the pressure of coping with new developments after Scrum meetings.
Experiencing such complex problems, the organization (buyer) decides to shift from Agile approach and to return to traditional waterfall model.
No doubt, Agile is more advanced software development model than to waterfall model but everyone likes to adopt the hassle-free model. So, what you need to do differently for successful and profitable outsourcing of Agile contracts?
Solutions for Hassle Free Outsourcing the Contracts in Agile:
Agile is built for long-term partnership nurtured with honesty and trust; if the buyer is contracting Agile project just for a short period, Agile model wouldn’t deliver the expected benefits. Agile implementation needs the mindset change of all the team members; investment in training and introduction of Agile tools will make the Agile team members more confident to perform better with gained technical excellence.
The trust between the seller and buyer is the key to success in an outsourcing environment. Agile team members must be free to accept the roles and responsibilities in their due capacity to avoid any pressure to deliver more than their capacity.
3.The Key Agile Contract Parameters:
Team size, sprint duration, procedure of identifying team’s velocity, story point standards based on scaled complexity, DOD (definition of done) etc are the key specifications that make outsourcing the contracts in Agile a pleasant experience.
4.Hybrid Styled Contract for Outsourcing Agile Project:
Agile project development can be stipulated into two stages in the context of outsourcing - stabilizing period and post-stabilizing period. You can choose to work with ‘Time and Materials’ (T&M) model during stabilizing period with an agreement to switch over to ‘Pay-per-story-point delivered’ model during the post-stabilizing period.
To improve the success rate of any Agile project, it is a must for the outsourcing vendor and client both to be equal partners in tasting the success and failure of project. The journey to Agile adoption is about accepting the changes in workflow, working culture and mindset; and, it takes time and improved skills to accept and incorporate changes. The certified Agile and Scrum training, focused on implementation of Agile development and Scrum practices, empowers you to complete each Agile project within agreed time at the best rate profitability that too without any compromise with quality parameters.
based on 4 customer reviews