Unleashing the Agile ‘Energy’ (by Nazarul)
Unleashing the Agile ‘Energy’ (by Nazarul)
Unleashing the Agile ‘Energy’
By: Nazarul Islam
Let me share with you, the hands on, experience of my childhood…..of learning how to ride a bicycle. Nearly a half century ago, this was my first exposure, to any kind of a mutually ‘conceived’ project. During those innocent years, I had enjoyed my carefree vision of sitting, balancing and moving myself, seated on a two-wheeler—a simple machine, called the bicycle. It would be a vehicle, designed to carry me lovingly into my future, and to the places I had wished to go….but for obvious reasons, could not do so!
There was my established need, coupled with a child’s urge to break his barriers. And, of course, the excitement and thrill of sneaking past those limitations, imposed by extremely, disciplined parents.
My eleven year old school friend Shafi, had contributed to this project, by risking his two principal assets—his time and his bicycle. My twelve year old neighbor, Rashid Nagi had responded to my pleas, by donating his precious time and counsel.
On a hot afternoon, in the dusty village thoroughfares of India (or Pakistan), you may have noticed the driver of a bullock cart— not so gently engaged, in ‘pursuading’ his two hard-working bullocks, to forge his vehicle forward.This vehicle is not just a rustic, old fashioned cart, but a fully functional man-animal-cart-integrated, mobile system!
Among the two (input) animals, one is always an ‘auxiliary’— a fake ‘puller’; someone who tags along….attached to the system, while his partner moves the loaded cargo! What does the auxiliary animal do? It only conveys the impression to his colleagues—his animal partner, and the human driver, that he works equally hard, therefore, he is an indispensable part of the entire moving, vehicular system.
As I came to grips with balancing my bicycle on the narrow lanes, I felt myself to be the key-person, the so-called driver of an ‘engine’ that could move things, or could drive the vehicle…or let’s say, ‘ride’ any bicycle successfully, to the close of this ‘project’, as its principal beneficiary.
The first two days of my coaching consisted of two-hour runs, each day, on the neighborhood streets. I sat happily on my seat, while my two auxiliary, human components held the vehicle and ran alongside, on both sides—gasping and panting, as they drained out energy. Not an inspiration, but a lot of perspiration!
At the end of riding sessions, my coaches would explain to me the physics and mechanics of the vehicle, in its state of motion and rest.
Perhaps Shafi had realized that, it wasn’t a good idea to invest his prime asset into this project—with a likely outcome of nothing tangible; perhaps a little more than a bondage or ‘amity’, measured against an unforeseen mishap, possibly leading to his asset, breaking apart on the winding roads. And, all this, while the beneficiary (me) had pedaled merrily, in his effort to break barriers!
On the third and final day of project, as I continued to pedal my learner vehicle, I realized, my coaches had nothing more to do with my ride. I was now, on my own, and could ride independently, without the active support of my two coaches.
That was the fleeting moment of discovery, that dreams could be conquered, and by way of a positive attitude, one’s visions could also materialize!
The rush of adrenaline had coupled with self pride, as I pedaled harder and harder, zooming in, straight into the nervously shaking legs of an oncoming pedestrian. The victim could not believe what hit him—in just a few moments. Both, the rider and his machine had separated. I could see the shocked faces of my two coaches, in the distance, desperately approaching the scene of mishap.
On the spur of that moment, I forgot where it hurt me—because I was not sure what would happen, after the injured passer by would wake up from his sudden sleep. I had realized—sometimes, an entrepreneur grossly miscalculates his or her outcome. For me, this was my watershed moment of pain and grief, rather than joy and ecstasy!
I will stop here, because what followed next, was something I want to forget. I had become the laughing stock of my town.
And now, the moral of this story: we may acquire a perfect knowledge of the physics and dynamics pertaining to bicycle and its moving parts, but this is not what had helped me to balance and ride my bicycle. It is one’s hands-on ability of self balancing, his approach to learning, which comes only through determination and practice.
And finally, the punch-line I wish to deliver, at this point: This is how the Agile methodology works, in incremental chunks of time called sprints, to deliver services; just as the goods are produced and delivered in a mass production system!
What I did learn in my training class and also while I had struggled to learn riding my bicycle, was that the sprint of time matters a lot while learning to reason and also to to create balance. It is a period of time allocated for a particular phase of a project. Sprints are considered to be complete when the time period expires.
There may be disagreements among the team members, as to whether or not the development is satisfactory; however, there will be no more work on that particular phase of the project. The remaining phases of the project will continue to develop within their respective time frames.
As trainees, we need to focus on the following, to arrive at our goals:
Satisfaction of the client and continual development efforts.
Changing requirements, aimed to benefit the client’s competitive advantage.
Concentration on delivering working products frequently. Delivery preference may be placed on the shortest possible time span.
Ensuring that Developers and business people must work together throughout the entire project.
Understand that Projects must be based on people who are motivated. Give them the proper environment and the support that they need. They should be trusted to get their jobs done.
Understanding that Face-to-face communication is the best way to transfer information to and from one another.
Understanding the concept that Agile processes will promote development that is sustainable. Sponsors, developers, and users should be able to maintain an indefinite, constant pace.
A conviction, that Constant attention to technical excellence and good design will enhance agility.
Making things Simple is considered to be the art of maximizing the work that is not done, and it is essential.
Understanding that Self-organized teams usually create the best designs.
I would also like to highlight the concept about sequential development. A project could be developed much like a product on an assembly line. Each phase of the development has to be complete before the next phase could begin. The idea requires that all developers must first put together all of the requirements of a project.
The next logical step is to complete all of its architecture and designs. This is followed by writing the code. The sequences continue in complete increments. As these steps are completed, there is little or no contact between specialized groups that complete each phase of the project.
Going back to the early years, the pioneers of the Agile Method had believed that if developers studied the process, they would find it to be the most logical and useful solution to product development.
This method offers a light framework for assisting teams. It helps them function and maintain focus on rapid delivery. This focus assists capable organizations in reducing the overall risks associated with software development.
The Agile Method ensures that value is optimized throughout the development process. The use of iterative planning and feedback results in teams that can continuously align a delivered product that reflects the desired needs of a client. It easily adapts to changing requirements throughout the process by measuring and evaluating the status of a project. The measuring and evaluating allows accurate and early visibility into the progress of each project.
It could be established that the Agile Method has helped companies build the right product. Instead of trying to market (software) products before being written, the Agile Method empowers teams to optimize the release during its development. This would allow the product to be as competitive as possible within the marketplace. It preserves the relevance of the critical market, and it ensures that a team’s work doesn’t wind up collecting dust on a shelf.
And now, let me focus on the terminology of SCRUM, derived from the English game of Rugby.
Scrum works by breaking each project up into bite size chunks, prioritizing them and delivering them in short bursts called ‘Sprints’.
The popularity of the Scrum framework likely stems from the way it deals with complexity and change. It does this in a similar way to how you or I would when faced with lots of work and not much time
The Application of Product backlog:
We a list of all the tasks or features that we would like to complete. In Scrum these issues are often called User stories and describe the user of the software that the feature is for, what they want to do and the reasons behind this!
Estimation
Every user story is given a score based on its assumed complexity. Common estimating methods include t-shirt sizes (S, M, L, XL), powers of 2 (1, 2, 4, 8) or the Fibonacci sequence (1, 2, 3, 5, 8, etc). We favor the Fibonacci sequence at Scalable Path and wrote a short article on why it is useful when developing digital products.
Grooming backlog:
Stories in the backlog are then prioritized by the client or Product Owner, based on their importance to the business. The stories near the top of the backlog need to be defined enough in order to begin working on them. It is less important to fully define stories that are low priority and not likely to be developed soon.
As we approach the close of training, we are given to realize that, we need to be
Retrospective in the rush to start the next sprint. But doing so regularly will affect growth and performance. Each team needs time to reflect on how they can become more efficient and adjust their behavior accordingly.
The Retrospective is, at its core, about how the team can optimize the way they work together. This should not be limited to discussions about the flow of stories through the process, but should include anything that affects output: from the attitude of the team through to the software being used.
If you feel you need a framework for this part of the meeting then you may want to categories all issues raised into the following buckets:
• Start doing
• Stop doing
• Continue doing
The retrospective is attended by the development team, the scrum master and the product owner.
We continue to learn from one another, and also from our errors and omissions. Let us strive together in our efforts to assist one another to make this world, a happy place to live and work in.
Good luck to all future Scrum Masters
The End.
The blogger is a former educator, based in Chicago.