The dos and don’ts of daily stand-ups

by Mattew Stibbe

Daily stand-ups are a core element of the Agile approach. They ensure that everyone knows what each team member is working on for that day and prevent delays – but only if you do them right. At Hewlett Packard Enterprise, we use daily stand-ups within our DevOps and Programme teams, as Peter Bailey, Programme Lead, explains here:

Daily stand-ups are a core element of the Agile approach. They ensure that everyone knows what each team member is working on for that day and prevent delays – but only if you do them right.

At Hewlett Packard Enterprise, we use daily stand-ups within our DevOps and Programme teams, as Peter Bailey, Programme Lead, explains here:

Depending on the variation of Agile project management that you use, stand-ups go by a different name, such as a daily scrum. While there are individual nuances to each approach the premise is always the same: to give everyone a clear picture of where the project is, what’s constraining or blocking us and what we need to do next to meet our goal.                        

There is no set agenda to follow, but there are some key dos and don’ts to make sure your stand-up meetings provide real value for your team.

DO put a clock on it

When you put a timer on a stand-up, you’re forced to mention only the really important points. This keeps the meeting focused, efficient and useful to all participants. Allow one or two minutes per person and try not to exceed 15 minutes total. 

DO keep them question-driven

Since the stand-up meeting is short, you need to have some form of loose agenda. The best option is to keep it question-driven:

  1. What did you accomplish yesterday?
  2. What will you do today?
  3. What obstacles are impeding your progress?

DO make them daily

Schedule them for first thing in the morning, every morning. By the end of each meeting you will have a clear idea of what each member of your team is working on and what roadblocks they face. 

DO remain standing

It may seem obvious, given the name, but the theory is that meetings held while standing up are faster and more efficient.

More importantly, they give everyone in your team a voice – a chance to talk about their work and to hear what their colleagues are working on. This is valuable in any project, but even more so in Agile teams where communication is key to success. 

DON’T try to problem solve

If a member of your team flags up a roadblock then by all means suggest a solution and look at having a separate session after the stand-up and asking those involved (or anyone who can help) to attend that. But the aim of these meetings is to give a high-level overview of the day. The more detail you go into and problems you try to solve, the longer it will take. During the meeting, make a note of any issues that arise and dig into them after.

DON’T micromanage

A daily stand-up is not a status report of every task your team has completed or will work on today. It can be tempting for a team leader, or Scrum Master, to press for details on a task mentioned in yesterday’s stand-up but this is not the forum for such talk. 

DON’T use the meeting to plan whole sprints

Your stand-ups are not strategy meetings. Even if a new requirement comes through before the meeting starts, the stand-up is not a place to reassign work. These kinds of conversations require a proper briefing and doing so would eat into your limited time. Stick to self-organisation and planning for the day.

Stand up and be counted

While the aim – to deliver information – is the same, stand-up meetings are not the same as a general company meeting. Daily stand-ups are about making best use of resources and preventing roadblocks.

More importantly, they give everyone in your team a voice – a chance to talk about their work and to hear what their colleagues are working on. This is valuable in any project, but even more so in Agile teams where communication is key to success.

Stand-ups have changed the way we work at HPE. Get the basics right and they can do the same for your organisation.

 

Original article link: https://community.hpe.com/t5/UK-Public-Sector/The-dos-and-don-ts-of-daily-stand-ups/ba-p/6878343

5 best practices for agile procurement

By Lawrence Fitzpatrick

Federal CIOs once spent nearly all their time on infrastructure. Today, however, thanks to commoditization and cloud technology, savvy CIOs are now grappling with the idea that they are no longer primarily infrastructure-focused leaders but rather key players in advancing their agencies’ missions.

As I wrote previously, CIOs must adopt an application development and management mindset. The shift can be difficult because the rules for managing infrastructure differ from those for managing applications. Nowhere is that difference starker than with procurement.

Civilian agencies are beginning to introduce agile delivery contracts, with U.S. Citizenship and Immigration Services’ Flexible Agile Development Services (FADS) contract serving as a model. Here are five best practices that can help government CIOs make the shift to agile procurement.

Award full-and-open contracts for small teams

The use of small teams, which is central to agile, is often distorted into a mandate to contract with small companies. That confusion has cut off access to more than half the talent pool and most of the real-world experience. Additionally, it drives up costs when small businesses can’t fulfill demand and must subcontract for talent, thereby adding multiple layers.

Instead, contracting for small teams regardless of company size levels the playing field.

 

Design contracts to reward delivery

Agile development is sometimes confused with “one and done” (a short development effort with no follow-on contract), and short contracts of three to six months are expected to reap results.

Mission-centric applications cannot be built in six months. Team effectiveness and efficiency take months to create; team and government collaboration takes quarters to build; and learning the application domain and mission can take years. Those factors contribute more to success than the development methodology alone.

Therefore, CIOs should award three- to five-year contracts, demand software deliveries at six-month intervals and replace contractors when they don’t deliver.

Use firm-fixed-price contracts with monthly milestone payments

The idea that a customer will know exactly what to build or the contractor will know precise staffing needs at the beginning of a project is pure fiction. Yet many contracts ask for a specific set of labor categories, turning the bidding process into a rate shootout.

Contracts should follow the FADS model, and specify what to deliver (working, tested, documented, maintainable code) under what working conditions (i.e., the technical and mission environment). With less specificity, the staff makeup is allowed to adapt.

In short, the government should buy delivery capacity, supported by a firm-fixed-price contract.

Rely on technical demonstrations

Traditionally, software development requests for proposals ask for 100 or more pages of text in response. How can the ability to deliver software be measured by prose?

Instead, the written technical approach should be six to 10 pages, and teams that pass an initial review should be evaluated based on a live test of their software delivery skill. Good agile contracts, like the General Services Administration’s 18F agile contract, require hackathon-like settings to measure bidders’ professional skills. Most serious professions accredit this way.

Look for past performance specific to agile delivery

Agencies should only consider contractors that have experience delivering with agile methods, specifically in the federal sector. Further, they should seek contractors that have experience helping stakeholders move toward agile methodology. A sound vendor will help agencies adopt good practices, while an inexperienced vendor can cause problems that agency executives won’t soon forget.

Keep in mind that even though an organization adopts agile procurement, the CIO is still a long way from nirvana. He or she needs to transform the IT shop, and that’s a topic I’ll discuss in the next article.

 

Original article link

Agile: Not a Method, but a Movement

 by Ravindra Savaram

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

When we hear the words "software development," we think of a series of processes to accomplish the task of developing a software application. We set certain functionalities and some properties for the application and develop it to meet the goal we set at its inception. A basic question that arises here is what happens if an application with similar functionality and properties appears in the market at less cost than what we are going to fix for our application? Obviously, we need to change the functionality of the product by developing a new product starting from the first stage of software development. In this process, the time, money, and human labor the company employs for developing the product get wasted.

We can say that Agile is a revolution in software development process. Agile describes the continuous interactions between the cross-functional teams at different stages in the process of software development. Why is this interaction needed? What is the result of these daily interactions? The different teams involved in developing an application must access the direction in which the project is moving and should closely monitor the market trend to compare their product with others and to make changes, if necessary, at any stage of the development process.

This is achieved through regular meetings between cross-functional teams at the end of the day or after a certain time in the application development. This way, the teams can discuss how to enhance the process of development by suggesting changes at different stages as needed. This is not possible in the traditional Waterfall model. Due to continuous meetings and alterations in the development process, Agile is termed as iterative and incremental and can be described as a movement, as it does not follow any specific process.

Understanding Scrum

Scrum is the manner in which the Agile movement is brought into an organization because of its flexible and uncomplicated nature. Scrum employs the following features in the process of software development.

  • Feedback based on experience.
  • Team self-management.
  • Make great efforts to build tested product within short repetitions.

Scrum has three kinds of roles.

  1. The Scrum team.
  2. The Scrum Master.
  3. The Scrum Product Owner.

1. The Scrum Team

It is a team of individuals working together to deliver a specific set of tasks assigned to them in the process of software development. The functions of a Scrum team are:

  • Show respect towards each other.
  • Follow the same norms and rules.
  • Strive towards a common goal.

2. Scrum Master

The difference between the Scrum Master and the team leader is in the name itself. The team leader is in charge of directing the team and assigning the work, whereas the Scrum Master observes that the team follows the rules and understands the method of Scrum entirely. The Scrum Master comes into the picture when the follow the rules of Scrum aren't being followed, and he or she only functions as an advisor to the team.

3. Scrum Product Owner

The Scrum Product Owner plays a key role in bringing success to the Scrum movement. The Scrum Product Owner stands at the point where the team members and other parties involved interact with each other. The Product Owner is involved in dealing with customers, marketing, and management because he must present the software requirements to the team.

Sprint

I discussed earlier that meetings are held in Scrum after each day or after certain specified time. So, a Sprint is defined as a certain amount of time during which a specific amount of work must be completed. A meeting or discussion will be held after that time. This is a repetitive process that occurs until the whole development process gets completed. Each Sprint starts with a planning meeting during which the Product Owner and the development team comes to an agreement on the work that must be completed within that Sprint. After the Sprint ends, the team will display their work to the project owner and based on the criteria laid down at the planning meeting, the project owner will accept or reject the work.

Conclusion

Numerous job opportunities are present in Agile in IT development projects for experienced as well as freshers who receive training in Agile. Agile is followed now in almost all the software development projects because of its unique approach to application development. This is a proven way of effectively managing software development teams and projects. The average salary for a job associated with Agile is on par with the salaries for most sought-after technologies today in the IT market. Choosing to study this collaborative and cooperative approach and getting certified in it can be a good career option.

 

Original article link

Scrum Master vs Product Owner Differences in skills, duties and responsibilities (Agile Methodology)

Agile is a methodology to do work in the easy and convenient way. Scrum is the most famous agile methodology. Every Agile methodology consists of four main roles, which are

  • Product owner
  • Scrum master
  • scrum team
  • stakeholder

In scrum software development methodology, Scrum master and product owner are two main roles, which are responsible for separate areas of the project. Both are necessary for the project. In Agile methodology Scrum master is a bridge between product owner and development team.

Scrum doesn’t have project managers. Instead, the team is empowered. They’re responsible for the outcome, and they can manage themselves. The classic project manager ‘boss’ of the team isn’t needed in Scrum.

 

 

by Jeff Sutherland

 

Scrum Master (SM)

In Agile development methodology, Scrum Master cares about that how the team’s work. Increases team efficiency, motivate his team, spins, argues for changes that will ensure quality and timeliness.
Ensure observance of DoD. Thanks to the measured velocity know how much work will be done in the Sprint. Thanks to the care of the compliance with the quality we are sure that the system does not fall on the second day after the start. Thanks to his soft work well.

Scrum Master Skills:

The Scrum Master ensures that daily stand-ups are held at a fixed time every day for up to 15 minutes.

 

 

by Jeff Sutherland, The Power of Scrum

 

  • Scrum master coordinate with his team friendly to make an ideal team for agile development.
    Scrum master improve the product quality.
  • Certified Scrum master certification, would be an advantage but not necessary
  • He protects his team from any distraction and helps them to stay focused and follow agreed-upon rules for scrum meetings.
  • He helps PO to maximize ROI to meet his objectives through the scrum.
  • He removes barriers between from product owner and development team.
  • Scrum master accepts tasks and encourages his team to meet the deadline.
  • Scrum master is like a coach who helps his team to perform better.
  • He has the full authority all over the process.
  • Scrum Master shield the team from any interference.
  • Scrum master Cooperate with the Organization, to track the company’s progress and process.
  • He helps his team to understand self-management and cross-functionality.
  • A good Scrum master has a Project management, Engineering, Designing, Testing background and disciplines.
  • He provides constant guidance to his team.

Duties of Scrum Master

  • He facilitates his team for better creativity and try his best to improve the efficiency of the development team.
  • Scrum master is responsible for managing scrum process in Agile methodology, with the coordination of scrum team.
  • Scrum master has the responsibility to removes the impediments for the scrum team.
  • Scrum master arranged daily stand-up meetings, scheduled meetings, demo, facilitate meetings and decision-making processes in order to ensure quick inspection and proper use of adaptation process.
  • He helps product owner to make product backlog in good shape and make it ready for the next sprint
  • Most important part of SM job is to remove impediments.
  • Conduct retrospective meeting.
  • Organize and facilitate the sprint planning meeting
  • Act as safeguard for team

Product owner (PO)

The product owner is a demanding position in agile methodology, PO need to understand the clear vision of a product from the customer, end user or stakeholders point of view. The product Owner is responsible for managing the product backlog and product backlog visibility. He ensures the business value of the product.

Product Onwer Skills

First-time product owners need time, trust, and support to grow into their new role.

 

 

by Roman Pichler.

 

  • The Poroduct owner should know the business value of product and customers demanding features.
    He should be available to the development team for the consultation, so that the team can implement the features correctly.
  • Product owner needs to understand the feature/program from the point of view of end-user, not from the point of view of the developer.
  • In most organizations marketing is discussed on the sales level, product owner job is to facilitate marketing persons and guide them to make those goals achievable.
  • The Product owner is responsible for the product, from a business point of view.
  • Product owner has a vision for the perfect product.
  • His focus is on ROI (return on investment).
  • He assesses values, Develop cases,themes and epics to ensure that work focuses on product strategy
  • He solves problems, complete trade-off analysis and makes decisions to stay on business deliverable commitment track.
  • He expresses the voice of the customers.
  • He collaborates with stakeholders during the concept development and visioning of the product.
  • He works with project managers and technical leads to priorities and determines the scope for product development cycles.
  • The product owner is client’s voice. His job is to report ROI, product effectiveness and risk analysis.
  • Sometimes the product owner and the customers are same, but sometimes the customers are might be thousands/millions of peoples.

Duties of Product Owner

  • Product owner attends sprint demo and sprint planning meetings. Attending daily scrum is also recommended but it’s optional.
  • He ranks the product features so that development team can clearly understand them.
  • Product owner is responsible for forming a deadline for the project.
  • His duty is to defines requirements and priorities.
  • He is responsible for determining the release date and contents.
  • is responsible for managing and developing the product backlog. He prioritized backlog of user stories for implementation.
  • His job is to define epics/user stories to Agile development team.
  • He needs to make sure that user stories are explained well and alway in right priority in backlog. Backlog grooming meeting practice is conducted by the team of product owners, but it’s optional in some organizations.
  • Spend some time with the team to prioritize/groom the user stories with few team members. Not all need to be involved.

Original article link

 

Agile estimation techniques: Here's how to do it right the first time

by Jennifer Lent

To estimate or not to estimate is the question. And expert Jennifer Lent asks author Johanna Rothman for her best advice on estimating just enough to make the customer happy.

There's a fundamental problem with Agile estimation.

Figuring out what a software team will deliver -- and when -- eats away at valuable project time and doesn't necessarily result in accurate estimates. That makes the "No Estimates" approach compelling for a lot of software pros, but not their customers. Customers just want to know when their software will be ready.

I got to talking about the Agile estimation quandary with Johanna Rothman, author of Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. As the title suggests, her approach is practical. I like it because it offers a middle ground between spending too much time on estimates and refusing to do them at all. I'd sum it up like this: Do some estimating, but not too much; build trust by showing the customer what you have done so far and what you will do next.

Here's some of the Agile estimation advice she shared with me in a recent phone conversation.

Agile estimation: What's it for?

How you approach Agile estimation depends on what, exactly, you want to estimate. Rothman said, for sequential, not parallel, projects, what the boss typically wants to know is, "When will you release the first value?" To answer that question, develop a product road map that states, "We'll do this feature here, this feature there, this feature here." It might not be perfect, but it gives the customer a feel for what will be done when, she said. The more specific you are, the more useful your estimate is.

For example, if you're building a transaction processing website, specify that the first deliverable will be the payment feature and then fill in further details. The first payment deliverable, for example, will support PayPal; further releases will let customers use the payment processor Stripe, and so forth. "You want to get started, to get something out there," Rothman said.

Agile estimation: Release criteria

When more than one project is in play, an Agile estimate aims to answer a different question: When will you finish this project and start the next? "There is pressure to get the first project done, and pressure to complete a second project as well," Rothman said. In an ideal world, you have sufficient resources to run the projects in parallel with two different teams. But when you don't, Rothman emphasizes the value of establishing release criteria, in addition to developing the roadmap of deliverables.

Here's her definition of the term release criteria: "How little can we do -- in the best possible sense of the word?" For example, release criteria for the transaction processing website include -- among other things -- the ability to process payments (some payment types now, others later) and adequate search capabilities. The idea is to release a minimum viable product, so you can move on to the next development project. "We don't need to do everything [at once]. We commit for little bit for now, and say what we need to do later," Rothman said. "Search works for now, and [going forward,] we'll update search with new features and performance."

Building trust

At the heart of Rothman's "we'll do this now and that later" approach is the idea of building trust between the software team and the customer. Rothman recommends doing demos every two weeks that show how a feature is implemented. "Senior management gets more confident [when you show them what you're doing]," she said. Often, management is satisfied with the team's progress and will not demand detailed Agile estimates for each feature.

But what if they do? "You have to take two weeks -- or a month -- and do a discovery project," she said. That involves identifying the full feature set and estimating a delivery date for each one. If management wants to see that level of detail, they have to allocate the time to make that happen, she added. "They don't like to do that." But until a team breaks down stories into smaller parts -- and figures out what's really involved in delivering each feature -- it's impossible to come up with reasonable Agile estimates, Rothman said.

 

Original article link

BENEFITS OF ADOPTING SCRUM FOR SOFTWARE DEVELOPMENT

By Maik Seyfert

Scrum is a simple and flexible software development methodology or framework. Scrum framework introduces alternatives to traditional project management systems such as Waterfall or Sequential development. In scrum we only have three roles; product owner who represents the clients or users, the scrum master who is the silent leader and the team.

From my experience, additional roles are not needed since they don’t usually bring extra benefits. The Scrum framework covers all the necessary aspects for successful software and product development. Instead of additional roles it is possible to have a product owner team, where the different product owners cover different areas of the product. Depending on the degree of innovation and uncertainty in your project, this might be even necessary since one product owner alone might be overloaded with coveringproduct backlog, user test or constraints for example.

Unlike the other methodologies, Scrum is an agile framework which is highly optimised to react to any changes within the development process to suit the vision of the product owners. In scrum, there are numerous opportunities for the product owners and the team to access the direction the project is taking within the development cycle. This is one of the major benefits of this methodology.

Contrast this to the other methodologies where the product owner who has the vision for the product isn’t in constant communication with the team thus leading to the possibility of a mismatch between the vision and the product. This can be quite expensive in terms of time and money. In Scrum, the team is in constant communication, any impediment, weakness, and risks are easily spotted and remedial actions taken.

Another major benefit of working with Scrum for software development is the competitiveness it affords. The market today changes much faster than it used to several years ago. This means that relevancy of a particular product could easily change within a very short period. The flexibility that Scrum offers helps deal with this situation. Teams can react in a faster manner this affords the development team the confidence that whatever they are working on is what the client and market needs.

Scrum encourages efficient collaboration and teamwork between all the participants. The product owner, scrum master, and the team hold regular meetings to communicate progress, changes, new ideas, feedback or problems arising. This is a basis for a successful project and ensures customer satisfaction. There is transparency all along the project. Agreed timeline are observed. There is high visibility of progress and predictable rhythm. In the end, there is mutual respect not to mention the fun that comes with collaborative functioning. However, one thing I often see going wrong isthat people actually respect the Scrum framework and rules but they fail to respect the principles of the Agile Manifesto, which is the underlying core for an Agile software development project. Ensure that you and your team are familiar with the Agile Manifesto instead of applying Scrum without it. As long as Agile principles are respected, Scrum works very well.

Scrum is a flexible software development methodology and will be easily adopted for any project. It is especially good for new product development, small growing organisations, and teams willing to adopt a new culture that enhances teamwork, collaboration, and enhanced performance. On the other hand, Scrum might be the best for large organisations that are already well established with little need for change. Such organisations tend to have rigid organisational structures and operational commitments which make decision making slow.

Scrum is a transformative agile product development methodology that helps teams work in a better way. It has become popular among development teams due to the many benefits it offers.

 

Original article link

TOP 10 SECRETS OF AGILE TRANSFORMATION WITH MICHAEL SAHOTA

By Valerie Senyk

I dutifully watch Scrum Alliance’s webinars whenever they offer something I want to learn about, so I recently attended Michael Sahota’s “Top Ten Secrets of Agile Transformation.”

Sahota is a bit of an Agile guru, and well-respected in the community. He founded the Toronto Agile Community, and can be seen at Scrum Alliance gatherings everywhere. He also facilitates a Certified Agile Leadership course. You can learn more about Sahota by going to his website www.agilitrix.com.

The webinar he conducted was fascinating, because by the time he went from #1 to #10, I realized his “secrets” were very simple, and that one could start with #10 and work backwards to #1 and learn the same things.

By simple I mean his points were clearly articulated and comprehensive.

Before enunciating his secrets Sahota started with the idea that “Culture is the #1 Challenge with Agile.” He asked, “What are we (agilists) doing to create resistance to a change of culture in an organization?” Mindset, he averred, is more important than the practice of Agile – by which he referenced creating safe and trusting relationships, engaging with others, promoting continuous learning, innovation and so on. On a continuum line with “practices” on one end and “mindset/culture” on the other, he urged practitioners to find a balance between the two.

And now for the count-up:

Secret #1 – Clarify the purpose of bringing in an Agile coach by asking “why?” Usually the answers have to do with improving the quality of a product and encouraging more collaboration.

Secret #2 – Focus on organizational goals (and drop the word “Agile”). If the goals are clear, as those articulated above, one can drop the Agile initiative and try another. Agile is not the goal, but focussing on doing and being Agile can set up the wrong expectations. You may say, “Of course we will likely use Agile to help us achieve the organization’s goals,” but remember that Agile cannot be the goal!

Secret #3 – Focus on growth (and drop “transformation”). The idea of transformation is that it is a painful process. It also implies an end point: one is transformed. The idea of growth is more natural, and transformation is really about creating healthy change and growth. It is ongoing.

Secret #4 – Increase awareness of the global context. Global trends mean that an organization must be growing to survive. A lot of organizations do not know how to read their engagement surveys, or don’t even have them. People’s talents are wasted when engagement is low, which leads to massive financial waste. Millennials demand change – will not seek to work in an organization that’s regressive or stagnant. An agile enterprise is resilient and anti-fragile. How well is an organization set up to thrive in the future?

Secret #5 – Increase awareness of organizational context – what’s happening in an organization? However, resist telling leaders that their organization is broken. Start with humility and compassion, and then show leaders that there is a lack of engagement by their members by reading the survey. It’s not about blame – have the leaders acknowledge this and say what they want to do about it. What difficult conversations are needed here? The coach must stand in the truth of what’s happening, listen and understand. Be real.

Secret #6 – Clarify the focus of the initiative. Is more time spent on tactical initiatives (as in, how do we work?), in strategic initiatives (what do we want to achieve?), or in cultural concerns (who do we want to be?)? Discuss what percentage of time is needed to spend on culture in order to have a bright future.

Secret #7 – Build a shared understanding of what culture is. Culture has to do with both consciousness (or energetic property) and structures. Consciousness includes identity, values, beliefs, and the unwritten rules and norms in an organization. It includes values such as safety, trust, people being valued… Structure (practices) and consciousness (culture) co-exist together and are inter-dependent.  Refer to the Agile Manifesto: people over process. – focus on structures without consciousness cannot succeed.

Secret #8 – Clarify the leaders’ role in growing. The consciousness of the leadership is most important. New organizational behavior requires new leadership behavior. Growth requires leaders go first! How do we invite them to go first?

Secret #9 – Honour the leaders’ freedom to choose. Do they wish to work on something tactical? Cultural? A coach must let go of what he or she wants. We cannot coerce people into believing what we believe.

Secret #10 – Growth can happen anywhere.You, as an individual, are the limit for growth.

Sahota suggests creating a culture-bubble in which consciousness and safety can be grown. In this last point he quotes Gandhi: “Be the change that you want to see in the world.”

I am aware that in the 45 minutes of the webinar, Sahota went through each point relatively quickly. Each one in itself provides room for reflection. For me, the fact that the tenth “secret” puts the onus on each individual to grow is telling; if we change, we can help those around us in their transformation. But that requires extra-consciousness, I think, and humility. Overall, Sahota points to values and culture within and without as the key.

 

Original article link