tag:blogger.com,1999:blog-50946805081461161632024-03-12T20:49:04.051-07:00Agile Candor - High Performance Engineering Culture | Software Development | Cloud ComputingRahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.comBlogger32125tag:blogger.com,1999:blog-5094680508146116163.post-8174175006228063912023-02-12T15:17:00.008-08:002023-02-12T16:35:26.350-08:0014 Essential Software Engineering Concepts for Engineers and Managers<p><span><span style="background-color: black; color: white; font-family: arial; white-space: pre-wrap;">There are many terms and concepts that are important for an engineer to be familiar with, in order to effectively build software. This post includes some of those terms. I will continually add to or update this list. </span></span></p><ol style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; counter-reset: item 0; display: flex; flex-direction: column; list-style-image: initial; list-style-position: initial; margin: 1.25em 0px; padding: 0px 0px 0px 1rem; white-space: pre-wrap;"><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Agile.</b> A flexible and iterative approach to software development that emphasizes collaboration, customer feedback, and adaptive planning. My experience and success with agile development was the inspiration behind starting this blog.</span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><span><b>DevOps.</b> A set of practices and tools that improve efficiency, speed, and reliability of the product </span>through automation and optimization of the software development and delivery process where operational efficiency is part of the development process. </span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><span><b>Continuous Integration and Continuous Delivery/Deployment (CI/CD).</b> A set of practices and tools that result in faster and more frequent releases, through </span>automation of building, testing, and deployment of software. A key part of CI/CD is to deliver software to production frequently and using techniques such as Test Driven Development, can significantly improve the results that teams get through CI/CD.</span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Test Driven Development (TDD).</b><span> With TDD, developers write tests before writing code. This helps ensure that code meets the desired requirements and improves overall code quality. This practice encourages developers to match the requirements to the behavior of their code before writing it, which can lead to fewer bugs and a generally more robust software.</span></span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Scalability.</b> The ability of a system to handle increasing load and demand, either by adding more resources or by improving its architecture. Cloud computing technologies, such as AWS provide various options to scale a system's load-bearing capabilities. </span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Performance Optimization.</b> The practice of making software run faster, consume fewer resources, and handle more concurrent users, in order to improve the user experience. Here again, cloud computing technologies like AWS provide several tools that can help you in monitoring and optimizing your system's performance.</span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Resilience.</b> The ability of a system to recover from failures and continue to function properly, even in the face of adverse conditions or circumstances.</span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Security.</b><span> The practice of protecting software and its users from unauthorized access, exploitation, and data breaches. Security was initially a big concern for organizations to adopt cloud computing, though now all cloud computing providers offer robust set of tools to manage permissions and credentials to address those concerns. </span></span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span><span style="background-color: black; color: white; font-family: arial;"><b>Cloud Computing </b>refers to the delivery of computing resources, such as servers, storage, databases, and software, over the internet. With cloud computing, organizations can scale their computing resources up or down as needed, and only pay for what they use, rather than having to make large upfront investments in hardware and software.</span></span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Infrastructure as Code (IaC). </b>The practice of using code to automate the provisioning and management of infrastructure, allowing for faster and more reliable deployment, scaling, and maintenance. AWS's CDK is a great example of IaC.</span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b><span>Model-View-Controller </span><span>(</span>MVC</b><span><b>) </b>is a design pattern that separates an application into the Model, the View, and the Controller components that are inter-connected. The Model stores & manages the data, the View displays the data, and the Controller handles the interactions between the Model and the View.</span></span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span><span style="background-color: black; color: white; font-family: arial;"><b>Microservices </b>is an architectural pattern where a large application is broken down into small, independent, and loosely coupled services. This approach enables developers to build, test, and deploy each service independently, leading to faster time to market and reduced risk of failure. Medium to large applications often use a combination of MVC and back-end microservices.</span></span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span><span style="background-color: black; color: white; font-family: arial;"><b><span>Software as a Service (</span>SaaS)</b> is a model where software is made available to customers over the internet, often for a subscription fee. SaaS providers host and manage the software, taking care of maintenance, upgrades, and security, and usually charge a fee for their solution. SaaS products help business customers to focus on their business processes rather than building software for needs that they share with other businesses. There are also several SaaS products for individuals and families.</span></span></p></li><li style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px; padding-left: 0.375em;"><p style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgba(59,130,246,0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 transparent; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 transparent; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 transparent; --tw-shadow: 0 0 transparent; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; border: 0px solid rgb(217, 217, 227); box-sizing: border-box; margin: 0px;"><span style="background-color: black; color: white; font-family: arial;"><b>Artificial Intelligence (AI) and Machine Learning (ML).</b><span> Technologies that allow computers to learn from data and make predictions or decisions without being explicitly programmed to do so.</span></span></p></li></ol><span style="background-color: black; color: white; font-family: arial;"><span face="Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"" style="white-space: pre-wrap;">It's important to have a general understanding of </span><span face="Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"" style="white-space: pre-wrap;">these concepts and they impact the delivery successful products</span><span face="Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"" style="white-space: pre-wrap;">.</span></span>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-52468375737767512692018-09-30T10:23:00.000-07:002021-03-20T08:22:07.458-07:00Being OPEN about Sprint demos<h4>Consider This</h4><br/>Someone is presenting the work that they have just completed. Compare and contrast the two scenarios below:<br/><h5><strong>ONE.</strong></h5><br/>"This is freaking awesome!", you think. At one moment, everyone in the room was listening intently - not a word was spoken by the audience. At another, multiple hands went up for questions. Then, there was debate, many questions answered, some actions noted. Finally, the whole room erupted with applause and appreciation for the presenter and for each other.<br/><h5><strong>TWO.</strong></h5><br/>"Is that all you got?", you can't help but wonder. The room is low energy - the audience is either trying hard to listen, is distracted - only pretending to listen, or just busy chatting with someone else. There are no questions asked, and of course, none answered.<br/><br/> <br/><br/>Which of the above scenarios would you like be a part of - in either role, as presenter or as audience?<br/><br/>If you have worked in software development for few years, with different teams or organizations where they demo their work every couple of weeks, then chances are that (like me), you have come across both of these scenarios.<br/><h4>OPEN Rules</h4><br/>Below are the <span style="color: #00ffff;"><strong>OPEN rules</strong></span> for presenting compelling Sprint Demos that rock:<br/><ol><br/> <li><span style="color: #00ffff;"><strong>Ownership</strong> </span>- Present it like you <strong>own</strong> it and <strong>acknowledge</strong> others who contributed. That will engage everyone who you acknowledge immediately, increase your credibility and tune in anyone who is interested in learning about what you and those you mentioned did.</li><br/> <li><span style="color: #00ffff;"><strong>Purpose</strong> </span>- Delve into questions like: <strong>What</strong> are you demonstrating, what <strong>problem</strong> does it solve, <strong>how far</strong> along you are in solving the problem, and what is <strong>unique</strong> about your solution?</li><br/> <li><span style="color: #00ffff;"><strong>Engagement</strong> </span>- As a presenter, it is up to you to make or break your demo. You can decide how you want it to be like - interesting, nerdy, funny, or anything else. Most importantly, show <strong>enthusiasm</strong> for the topic, as without it you will sap the <strong>energy</strong> out of the whole experience. Some things to think about: What is your presentation style? When you speak, can they hear you, understand you? Are you okay being interrupted with questions during the demo or do you want everyone to wait till you have completed your demo? If you do mind being interrupted during the demo, then letting the audience know when you start is a good idea.</li><br/> <li><span style="color: #00ffff;"><strong>Next steps</strong></span> - A demo is a way to present your progress. So, you might have next steps related to what you presented in the following sprint or later. Letting everyone know what those are and what to expect reduces the chances of surprise in the next demo. Plus, you should expect feedback during the demo - most good demos receive new ideas worth exploring or specific things to work on. Make sure you capture it all (better yet, have someone on the team do so) and mention what you will do about the feedback. As you close out, thank everyone for their participation.</li><br/></ol><br/>Hope you have wonderful demos!<br/><h4>Related Reading</h4><br/>(1)<br/><br/>https://georginahughes.com/2017/10/16/power-start-your-meetings/<br/><br/>(2) <a href="http://www.quietagilist.com/blog/2014/10/29/im-not-coming-to-your-bad-meeting" target="_blank" rel="noopener">I'm Not Coming to Your Bad Meeting</a>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-36865674327301969672017-07-13T09:02:00.000-07:002021-03-20T08:22:07.403-07:00Create change... then get rid of it!Someone said to me, just a few months ago - "<em>There are two ways to deal with something you don't like. One is to try to change it and another is to accept it</em>". The advice came from someone I had come to respect, yet the notion of accepting something that I don't like made me uncomfortable.<br/><br/>After thinking about it, and naturally falling back to the ethos of agile software development, I argue that the advice is sane and is closely related to managing change.<br/><br/>Here is what I think:<br/>1. Responding to change sometimes requires <strong>creating the change</strong><br/>2. Any change requires <strong>prioritization</strong><br/>3. Some changes need to be <strong>shortlived</strong><br/>4. Some changes are <strong>not worth it</strong><br/>5. Some changes <strong>leave a mark behind</strong><br/><h5>Creating the change</h5><br/>It is unnatural to me to accept something that I don't like straight away. So I try my best to make a change and make things better. If I don't even try, would I be doing my duty towards making the situation better? To me, this is about thinking about the change that should be made and how will I know that I have succeeded. This is the first step.<br/><h5>Prioritization</h5><br/>What if we treat all changes with an identical sense of importance and urgency? When everything becomes urgent and important, we become perfectionists and lose sight of what is valuable. The perfectionist approach usually results in too much work in progress that reduces focus and we get nothing done.<br/><h5>Shortlived changes</h5><br/>I used to think that changes are meant to persist. Now, that is hardly true! Too many changes are just transient. Their purpose, for example, maybe to trigger further changes or to be quick fixes so we can tackle an immediate problem at the moment.<br/><h5>Changes Not worth it (or Worth being patient about)</h5><br/>There are many changes that are just not worth trying. Maybe there are alternatives, or maybe it is just better to wait for the situation to just evolve. Jumping the gun doesn't solve a thing, in these cases. This is about accepting how things are at this moment, and not about giving up.<br/><h5>Changes that leave a mark behind</h5><br/>There are changes that we should really care about. Involve people who will be our partners, chart a course that will lead us to our desired state. Doesn't matter whether the change is small or big, although I am biased towards small changes as of now (it is 2017 and I am still about short Do/Build, Test and Learn cycles). Eventually, the change should not feel like a change... it should blend so much with the environment that it should feel like you've gotten rid of it!<br/><br/>Would love to hear your thoughts, what do you think?Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-67382305530326570742017-05-14T16:57:00.000-07:002021-03-20T09:10:15.888-07:00Six steps to unlock your team's true potential<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWgGRw1K0SZ7xvIpE2k8MEhs1_eLdqGjAQFlc0SF7Wyy9fimoyMrodgx5XLlBqQ7gVrRHSbQThW_TZAfo9-D436CvztiJiQ63uqpAyrtIjRpULMCHn2ek3HWat82f0roJPhxhoOaiBHBY/s660/youth-570881_1280.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="440" data-original-width="660" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWgGRw1K0SZ7xvIpE2k8MEhs1_eLdqGjAQFlc0SF7Wyy9fimoyMrodgx5XLlBqQ7gVrRHSbQThW_TZAfo9-D436CvztiJiQ63uqpAyrtIjRpULMCHn2ek3HWat82f0roJPhxhoOaiBHBY/s16000/youth-570881_1280.jpg" /></a></div><br /><h3 style="text-align: left;"><br /></h3><h3 style="text-align: left;">What's true potential?</h3>My definition of true potential is a state of being where performance is maximized even when the situation is hard, or even too hard. When someone or something reaches its true potential it reaches the state of hyper-performance without fear, not hyper-performance with stress.<br /><h3 style="text-align: left;">Why is it hard to achieve?</h3>I have often seen fear cast a shadow over our existing potential, making it hard to see. Fear can manifest itself anywhere at anytime. At other times, it may be quite evident. At times, it may be invisible but it is there. When we can't see our existing potential due to fear, it is even harder to see what true potential might look like.<br /><br />This is true not only for individuals but also for teams. It is easy to see that a team is made up of individuals, who have their own fears. In the worst case, the team's fear could be compounded by multiplying the fears of rest of the teams. Yes, we definitely don't want that!<br /><h3 style="text-align: left;">Addressing the Ecosystem</h3><br />The ecosystem in which teams operate have a huge impact on their performance and can deter or improve their chance of unlocking their true potential. Here are some ways of addressing the ecosystem.<br /><h4 style="text-align: left;"><strong>Noise cancellation</strong></h4><br />Team members' fears can act as noise cancellation mechanisms for other team members' fears. How?<br /><br />Let us take an example. Say that a QA on the team is afraid of receiving bad delivery from developers. Now assume that a developer on the team is afraid of poorly groomed stories. These fears when looked upon by themselves can cause a lot of pain and strife. Now put their fears together. Poorly groomed stories often mean that it is not clear what the expectation downstream is, so it makes harder for the developer to code which results in poor delivery to the QA. OTOH, if the whole team was aware of these fears, they could all get together to discuss how the story needs to be tested (the T in INVEST) before starting to work on it.<br /><br />In other words, certain fears can help guide positive collaboration between the team members and give them the courage to deal with problems. I find retrospectives are an essential noise cancellation tool in any team's arsenal. So if you find your team skipping retrospectives or having them only for namesake, then hopefully you know what to do.<br /><h4 style="text-align: left;">The Role of Leadership</h4>Some researchers at Google through their project Aristotle found that high performing teams have a psychological safety. Modern Agile also lays it down as one of the four cornerstones. I believe psychological safety is everyone's responsibility but the lion's share of the responsibility falls on the leaders of the organization. Why?<br /><br />Leaders of the organization heavily influence how it operates. They influence the structure; their decisions and behaviors either create or destroy walls between people based on their departments or functional groups. Even at the team level, leaders influence relationships between people. Negative influence can create mistrust, and positive influence can help the team soar even in most difficult situations.<br /><br />Unfortunately, there are always some things that cannot be discussed openly even in the most open of all organizations and teams. Sometimes that creates fear. It is the leaders' job to sense what those things are and how they impact the safety of their people. Leadership's role cannot be downplayed.<br /><h4 style="text-align: left;">Understanding True limits</h4>When you have canceled the noise and you have leadership support, look into what you can do to learn about your current limitations. A useful conversation to have is around - To what extent can you go today without getting into trouble?<br /><br />Take an example, a team perceives that it is delivering slowly. However, it does not know how fast it goes today. Now, the team may try different approaches to go faster, like slicing user stories or reducing work in progress. It may even work but if it is afraid of measuring its progress objectively and often, it may easily fall back to old ways. This would create more fear for change and would be counter productive.<br /><h3 style="text-align: left;">The SIX STEPS: What to do?</h3>Here are six steps to unlock your team's true potential and become the best team ever:<br /><ol><br /> <li><strong>Find out what your limits are.</strong> Only if you know your limits, you can challenge them.</li><br /> <li><strong>Identify what to do</strong> to get as close as possible to the limits.</li><br /> <li><strong>Get permission to fail</strong>, and give yourself the permission to fail.</li><br /> <li><strong>Do what you need to</strong> in order to get close to the limits.</li><br /> <li><strong>Fail or not</strong> - <a href="http://www.agilecandor.com/retrospectives-10-ideas-agile-teams/">Retrospect</a>, learn from the experience, what can you do to push the limits? Push the limits.</li><br /> <li><strong>Repeat</strong> from step 1</li></ol><br />Unlocking your team's potential can be easier than you think. The one hard thing about it is that it requires an open culture based on trust and respect. Even then, these six steps should help take things from where they are, towards where they should be.<br /><br />Image courtesy:https://pixabay.com/en/youth-active-jump-happy-sunrise-570881/Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-78382761326614222452016-11-28T20:20:00.000-08:002021-03-20T12:15:15.289-07:005 Agile Quotes: Kung-Fu-Panda-3<p style="text-align: left;">I love the Kung Fu Panda movies, hope you enjoy them too. Apart from the funny awesomeness of Po the panda, I love the subtle and not so subtle messages and quotes these movies contain. Here are few gems from Kung Fu Panda 3. I only saw it this week, so am sharing these now.</p><br /><br /><br />[caption id="attachment_283" align="aligncenter" width="595"]<div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhE9ZEAYK8Yxng78WvM_LJYFpZWGeeGiGPSr9_lG8zhmWBBahLb1TNsxBJq17T2cYELZM9dGXIJOCXGc9ycwYyTNpoENr-fh-II08Q2AkwJl7eeLerggEMRU2b7oM5VorDcD1n74B9ZxSw/s640/PoPanda.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="640" data-original-width="577" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhE9ZEAYK8Yxng78WvM_LJYFpZWGeeGiGPSr9_lG8zhmWBBahLb1TNsxBJq17T2cYELZM9dGXIJOCXGc9ycwYyTNpoENr-fh-II08Q2AkwJl7eeLerggEMRU2b7oM5VorDcD1n74B9ZxSw/s16000/PoPanda.jpg" /></a></div><br /> Rock like Po the panda![/caption]<br /><p style="text-align: center;"><span style="color: #999999;">Image courtesy: https://www.flickr.com/photos/27474697@N08/2556889334/</span></p><br /><p style="text-align: left;"><strong><em>1. When will you realize the more you take, the less you have?</em></strong> - Master Oogway to Kai (the beast)</p><br />When Kai tells Master Oogway that he has taken the chi of every master there is, Master Oogway pleads to Kai to realize this. There is a virtue in giving; always give when you can! So how is this connected to agile? There are examples. It could be giving help to a struggling team member, or giving credit to someone else who deserves it, or giving someone encouragement for their effort, or giving someone any other type of support they need - mentally, physically and emotionally.<br /><br />Look beyond yourself. There is great power in humility and kindness, it helps build strong relationships that help teams thrive.<br /><h5><em><strong>2. If you only do what you can do, you'll never be better than what you are.</strong></em> - Master Shifu to Po</h5><br />This one is straightforward. A core tenet of agile is to keep challenging oneself to do better than today. Never cease to challenge the status quo, it is a key to customer and team happiness.<br /><h5><em><strong>3. I have so much to learn!</strong></em> - Po after the party at the secret Panda village</h5><br />Learning is essential for an agile mindset. Learning manifests itself everywhere. There is always more to it than meets the eye, but one should be willing to see beyond what is visible.<br /><h5><em><strong>4. You gotta let the hill tell you where to roll.</strong></em> - Li, Po's panda dad during Po's training</h5><br />This one is interesting. Agile mindset encourages to be courageous and to experiment. Let the results tell you what to do next. Surely there can be failures along the way. Accept successes and failures as normal events, but don't let the causes become your excuses.<br /><h5><em><strong>5. Feeling relaxed? Just let yourself fall into it</strong></em> - Li, Po's panda dad during Po's training</h5><br />This is a natural deduction for the previous quote. Immerse yourself into the environment and let it guide your actions thoughtfully. Not only will you increase your chances of success, you will also tremendously increase the enjoyment you get from your experience.<br /><br />That's all for now! If you have more quotes to share from Kung Fu Panda or anywhere else, I would love to hear :)</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXurEEsM_tv7AUDK8ow4fIc5P4I1gswOXGJceKMSuN_dZyltcnAda-AJIYqt5sWIFniK8RbZQuL_fQntWxMEokzgwCd313CtrAubhxGZWJ5LUN_GyF_gvkBPqno7m_gxab-aGg-soY9lk/s640/PoPanda.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="640" data-original-width="577" height="115" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXurEEsM_tv7AUDK8ow4fIc5P4I1gswOXGJceKMSuN_dZyltcnAda-AJIYqt5sWIFniK8RbZQuL_fQntWxMEokzgwCd313CtrAubhxGZWJ5LUN_GyF_gvkBPqno7m_gxab-aGg-soY9lk/w104-h115/PoPanda.jpg" width="104" /></a></div><br />Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-31138042017240230672016-11-18T03:31:00.000-08:002021-03-20T12:24:02.069-07:00Make onboarding fun with Onboarding Canvas!<span style="font-weight: 400;">The </span><i><span style="font-weight: 400;">Onboarding Canvas</span></i><span style="font-weight: 400;"> is a tool that can be used for onboarding a new team member</span><span style="font-weight: 400;">. We derived this tool from </span><a href="http://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">Spotify's adaptation</span></a><span style="font-weight: 400;"> of the </span><a href="http://www-personal.umich.edu/~mrother/Homepage.html" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">Toyota Kata</span></a><span style="font-weight: 400;">. I like this tool because no one can tell you precisely how your onboarding should be like in order for you to be effective at your new job. This is a tool for continuous reflection and adaptation. It puts the newcomer in the driver’s seat, makes the onboarding process agile through continuous collaboration with your team.</span><br /><h3><span style="font-weight: 400;">Four quadrants</span></h3><br /><span style="font-weight: 400;">The onboarding canvas has four quadrants:</span><br /><ol><br /> <li style="font-weight: 400;"><b>Now:</b><span style="font-weight: 400;"> It defines where the team is now, what is going on and how is the new team member adapting to the change?</span></li><br /> <li style="font-weight: 400;"><b>Definition of awesome:</b><span style="font-weight: 400;"> With the addition of the new team member, how would the team like itself to be? What would be awesome for the new team member?</span></li><br /> <li style="font-weight: 400;"><b>Next target:</b><span style="font-weight: 400;"> In order to move towards "Definition of awesome" what outcomes should be achieved in the next x weeks?</span></li><br /> <li style="font-weight: 400;"><b>Next steps:</b><span style="font-weight: 400;"> What are the immediate next steps for the team and when are they due?</span></li><br /></ol><p style="text-align: center;"><i><span style="font-weight: 400;"></span></i></p><div class="separator" style="clear: both; text-align: center;"><i><span style="font-weight: 400;"><br /></span></i></div><i><span style="font-weight: 400;"><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgz1oPq2UepF-ZEKLN0-6q1mwBfVaBUfzkICUqCye7ej6U8KsxgAAb3-DiRqipYgIBu1qKfAa3Zf6fA7wLSuMa7UCrs7JQUw-7TsSaj5MC3ugzt30m49W4lsxJ9eZrWlVZhyphenhyphenUVtGiT1jfQ/s1030/Onboarding-Canvas-1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1030" data-original-width="1030" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgz1oPq2UepF-ZEKLN0-6q1mwBfVaBUfzkICUqCye7ej6U8KsxgAAb3-DiRqipYgIBu1qKfAa3Zf6fA7wLSuMa7UCrs7JQUw-7TsSaj5MC3ugzt30m49W4lsxJ9eZrWlVZhyphenhyphenUVtGiT1jfQ/s320/Onboarding-Canvas-1.jpg" /></a></div><br />Onboarding Canvas</span></i><p></p><br /><br /><h3><span style="font-weight: 400;">Using the Onboarding Canvas</span></h3><br /><span style="font-weight: 400;">Collaborate with the new team member to fill the onboarding canvas and iterate regularly. </span><br /><br /><span style="font-weight: 400;">In your first session, brainstorm on the </span><b>Now</b><span style="font-weight: 400;"> and the </span><b>Definition of Awesome</b><span style="font-weight: 400;">. Use post-its or whiteboard to gather ideas. Group ideas together into themes if themes emerge. Have a lively discussion and get excited about new possibilities that have opened up as a result of someone new joining the team!</span><br /><p style="text-align: center;"><i></i></p><div class="separator" style="clear: both; text-align: center;"><i><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiT2OsR3Aj378us4C2GbR90BheHpYnSyC7U3F88B57WLLY5Ac1-2aPiSZyDkGs_YkkpqqC3_Amzq4UHFjL192DmjYOQotybIhYkuE0Kjmy7rZEJGBEfVAcyS__2Fj8CoHYpdEyLyLdjQrI/s1030/Onboarding-Canvas-2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1030" data-original-width="1030" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiT2OsR3Aj378us4C2GbR90BheHpYnSyC7U3F88B57WLLY5Ac1-2aPiSZyDkGs_YkkpqqC3_Amzq4UHFjL192DmjYOQotybIhYkuE0Kjmy7rZEJGBEfVAcyS__2Fj8CoHYpdEyLyLdjQrI/s320/Onboarding-Canvas-2.jpg" /></a></i></div><i><br /><span style="font-weight: 400;"><br />Onboarding Canvas: Now and Definition of Awesome</span></i><i></i><p></p><br /><span style="font-weight: 400;">Meet the whole team again in few days, and together identify the outcomes that should be achieved within the next few weeks - this is your </span><b>Next Target</b><span style="font-weight: 400;">. The Next Target has a due date, that is usually few weeks or a month later.</span><br /><br /><span style="font-weight: 400;">Using Next Target as the basis, derive the </span><b>Next Steps</b><span style="font-weight: 400;">. Each next step may have an owner and a due date that is prior to the next target date. </span><br /><p style="text-align: center;"><i><span style="font-weight: 400;"></span></i></p><div class="separator" style="clear: both; text-align: center;"><i><span style="font-weight: 400;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiG0x_bItywxmC0a8dt_INiha5PLk-qCobBLv0XrGei6CQ4LHqqT8kPdkdRFXjgI3XlHsFta0TtnqWD50nkQYVZF-O4yIjAo_pi9EYU49HsOt_Sj07psgfe0ehXHXTrWLaEZ8d1gknE_Zk/s1030/Onboarding-Canvas-3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1030" data-original-width="1030" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiG0x_bItywxmC0a8dt_INiha5PLk-qCobBLv0XrGei6CQ4LHqqT8kPdkdRFXjgI3XlHsFta0TtnqWD50nkQYVZF-O4yIjAo_pi9EYU49HsOt_Sj07psgfe0ehXHXTrWLaEZ8d1gknE_Zk/s320/Onboarding-Canvas-3.jpg" /></a></span></i></div><i><span style="font-weight: 400;"><br />Onboarding Canvas: Next Target and Next Steps</span></i><p></p><br /><span style="font-weight: 400;">Meet regularly to revise the canvas. The whole team should be present for reviewing the progress. A good rule of thumb is to review progress every two weeks, to begin with, and tweak the frequency as needed.</span><br /><br /><span style="font-weight: 400;">Revisit the </span><b>Now </b><span style="font-weight: 400;">and</span><b> Definition of Awesome</b><span style="font-weight: 400;"> when things have changed significantly and you have seen progress. </span><b>Practice iterating with the team! </b><span style="font-weight: 400;">Without practice, this is of no use. Iterating on the onboarding canvas is like planning and retrospective combined together. While iterating, think about what has been going well, and what needs to change. Continue until you and the team feel the canvas is providing you value. Although the number of iterations depends on your situation and needs, I suggest using the canvas for six months and reducing the frequency of iterations during the period.</span><br /><br /><span style="font-weight: 400;">Note that no two canvases are alike. Everyone arrives with their own experiences, needs, skills and interests. Furthermore, the environment is always changing and the demands of the environment change with it. The onboarding canvas easily adapts to the dynamic nature of our organizations. It is agile: The canvas continuously evolves, improves and delivers what is important to its users quickly and incrementally. It is collaborative, and it is easy to understand. It makes onboarding fun and creates trust between the team members.</span><br /><h3><span style="font-weight: 400;">Completion</span></h3><br /><span style="font-weight: 400;">The team can stop iterating on the canvas when the new team member and the team both agree that the onboarding is complete. The team should find itself closer to realizing its Definition of Awesome than when they started. The Definition of Awesome should have also undergone changes during this period.</span><br /><h3><span style="font-weight: 400;">What else is there to it?</span></h3><br /><span style="font-weight: 400;">If the simplicity of this tool interests you in digging deeper, you will see that this tool can be used not just for onboarding but in general for making simple improvements! For onboarding, I recommend using this tool as part of <a href="http://www.agilecandor.com/forget-onboarding-do-alongboarding/">Alongboarding</a>, a method that makes the onboarding experience wholesome and agile. If you are interested in exploring even further, refer to the </span><a href="http://www-personal.umich.edu/~mrother/Homepage.html" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">Toyota Kata</span></a><span style="font-weight: 400;">. That will definitely spur more ideas. </span><br /><h3><span style="font-weight: 400;">Summary</span></h3><br /><span style="font-weight: 400;">This is just one way to use the onboarding canvas, improvise it any way you like! The bottom line is that in order to get the most from it, your approach should be </span><b>collaborative, iterative and incremental.</b><span style="font-weight: 400;"> Make sure to include the whole team, including the new team member, in the dialog.</span><br /><br /><span style="color: grey;"><b><i>Credits and References</i></b></span><br /><ul><br /> <li><span style="color: grey;"><i><span style="font-weight: 400;">Thanks to my onboarding experience at </span></i></span><a href="https://www.appfolio.com/" rel="noopener noreferrer" target="_blank"><i><span style="font-weight: 400;">AppFolio</span></i></a><span style="color: grey;"><i><span style="font-weight: 400;"> and the wisdom of these coaches, I can say that this method works. Thanks, Ellie Thomas, Heidi Helfand, Jennifer Payne, Paul Tevis and Valerie Clarke!</span></i></span></li><br /> <li><i><span style="font-weight: 400;"><a href="http://blog.crisp.se/author/jimmyjanlen" rel="noopener noreferrer" target="_blank">Jimmy Janlén</a></span></i><span style="color: grey;"><i><span style="font-weight: 400;">:</span></i><i><span style="font-weight: 400;"> </span></i></span><a href="http://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata" rel="noopener noreferrer" target="_blank"><i><span style="font-weight: 400;">Improvement Theme – Simple and practical Toyota Kata</span></i></a></li><br /> <li><span style="color: grey;"><i><span style="font-weight: 400;">Mike Rother: </span></i></span><a href="http://www-personal.umich.edu/~mrother/Homepage.html" rel="noopener noreferrer" target="_blank"><i><span style="font-weight: 400;">Toyota Kata</span></i></a><span style="color: grey;"><i><span style="font-weight: 400;">.</span></i></span></li><br /> <li><span style="color: grey;"><em><span style="font-weight: 400;">The Center for Nonviolent Communication: </span></em></span><em><a href="https://www.cnvc.org/Training/needs-inventory" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">The needs inventory</span></a></em><span style="color: grey;"><em><span style="font-weight: 400;">.</span></em></span></li><br /> <li><span style="color: grey;"><em><span style="font-weight: 400;">Wikipedia: </span></em></span><em><a href="https://en.wikipedia.org/wiki/Onboarding" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">onboarding</span></a></em><span style="color: grey;"><em><span style="font-weight: 400;">.</span></em></span></li><br /> <li><em><a href="http://www.agilecandor.com/forget-onboarding-do-alongboarding/">Forget Onboarding, do Alongboarding!</a></em></li><br /></ul>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-7799253875190254502016-11-18T00:31:00.000-08:002021-03-20T12:25:41.293-07:00Forget Onboarding, do Alongboarding!<h3><strong>Alongboarding, an agile onboarding approach</strong></h3><br /><p style="text-align: center;"><i><span style="font-weight: 400;"></span></i></p><div class="separator" style="clear: both; text-align: center;"><i><span style="font-weight: 400;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL4dnsOmN0yTI9Zh6cPjzoPu5wvDj-33DRvi2T1zPC6CzRxRU2_tgqRrjhSAfvOEfUO65ESbBqgIi7uGexXdcbJOXKU2F91_blSb39r2f0kvuydaUDDIjE1PGdJ2LOh0qRNf2DUWqKKH8/s1030/Alongboarding.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1030" data-original-width="1030" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL4dnsOmN0yTI9Zh6cPjzoPu5wvDj-33DRvi2T1zPC6CzRxRU2_tgqRrjhSAfvOEfUO65ESbBqgIi7uGexXdcbJOXKU2F91_blSb39r2f0kvuydaUDDIjE1PGdJ2LOh0qRNf2DUWqKKH8/w400-h400/Alongboarding.jpg" width="400" /></a></span></i></div><i><span style="font-weight: 400;"><br />Alongboarding: We’re in it together!</span></i><p></p><br /><span style="font-weight: 400;">Organizations hire new people every day. A great first impression can make a tremendous difference in retaining employees. No one gets a second chance to make a great first impression, not even the best companies. An onboarding experience is an essential part of making that first impression on a new employee. Agile has been around for many years and has gained vast acceptance throughout the community. Yet, I find it disappointing that its tenets are not used well in most companies and most onboarding approaches follow a waterfall approach. </span><br /><br /><i><span style="font-weight: 400;">Alongboarding</span></i><span style="font-weight: 400;"> is an agile onboarding approach that applies agile tenets to onboarding new employees and makes the experience richer and more fulfilling. </span><br /><br /><span style="font-weight: 400;">When I joined </span><a href="https://www.appfolio.com/" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">AppFolio</span></a><span style="font-weight: 400;"> as an agile coach, I experienced this approach during my onboarding. It felt like the team owned my success as much as I owned the team's success. It was a welcome change from some of my earlier experiences where employee onboarding was a formality, or a wasted expense, or just a checklist, or nothing.</span><br /><h3><span style="font-weight: 400;">What’s in it for me?</span></h3><br /><h4><span style="font-weight: 400;">If you are joining a new company</span></h4><br /><span style="font-weight: 400;">Are you joining a new company or stepping out of school for your first job? Are you overwhelmed with too many questions on what the future might hold? Questions such as: How will you be treated? What will be your responsibilities? How will you prove yourself? Will the people you work with be cordial and supportive? How will your manager treat you? How flexible will your new role be? etc. etc. Depending on your situation, </span><a href="https://www.cnvc.org/Training/needs-inventory" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">you may have different needs</span></a><span style="font-weight: 400;">. It is not uncommon to feel vulnerable, somewhat scared or even have questions about your ability to adapt to this big change. Wouldn’t it be helpful if your new company or team had an approach to </span><a href="https://en.wikipedia.org/wiki/Onboarding" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">onboarding</span></a><span style="font-weight: 400;"> to take care of your needs?</span><br /><h4><span style="font-weight: 400;">If someone new is joining your team</span></h4><br /><span style="font-weight: 400;">Do you have someone new joining your team? It is a big change for you too, especially since most agile teams are small. You will soon be spending a lot of time with this person solving problems, hopefully, while having fun. If you have a healthy environment, the success and happiness of the new team member are tied to your success and happiness, closely. This is regardless of whether the new team member is your peer, your manager, or someone who reports to you.</span><br /><h3><span style="font-weight: 400;">Ready? Get set!</span></h3><br /><h4><span style="font-weight: 400;">Get real</span></h4><br /><span style="font-weight: 400;">Are you ready to welcome a new team member into the fold? The first step really is the realization that the new job will be a huge change for the new person and your team. Without this realization, no amount of work you put in will ever help you be as effective as you possibly can.</span><br /><h4><span style="font-weight: 400;">Prepare for the first day and week</span></h4><br /><span style="font-weight: 400;">A great first day and week of work not only sets a positive tone for the new employee's new journey but also forms a foundation for great relationships with colleagues. My experience suggests that we can remember our first day at our new workplace for a very very long time. Below are some preparatory actions that may be useful to help prepare for that awesome experience. It is recommended that the list is collaboratively prepared by the entire team. </span><br /><ol><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">First-day list: Before welcoming a new employee, make a list of things they will be doing on their first day. The list may include and may not be limited to:</span><br /><ol><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">When and where they will arrive, who will greet them. Will they be treated to a nice breakfast, a smoothie or maybe something else - a small, nice, welcoming gesture?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">What documents should they bring if any, and who needs them and why?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">When will they be introduced to the team?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">When will they meet their manager?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">Who will they go have lunch with? Can the manager or team take them out for lunch on their first day?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">Who else will they meet on their first day and at what time?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">How and when will they get their equipment, their access to company systems, and their seat?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">Will they pair with someone during their first few weeks to learn the ropes?</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">Will there be any training involved?</span></li><br /></ol><br /></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">One week in advance, inform the new team member about the plan for their first day. </span><span style="font-weight: 400;">When he/she is aware that you've been planning their first day, it alleviates stress and gives a feeling of belonging to something larger and intentional.</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">Prepare an initial checklist. It is not an exhaustive list of everything they will need to do. It is just something to get them going and give them a head start - into a path of discovery. In </span><i><span style="font-weight: 400;">Alongboarding</span></i><span style="font-weight: 400;">, they will own the checklist and drive it from the get go.</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">In the checklist include meeting everyone who the new team member will collaborate with. Add other stakeholders, and support team members - who they need to know in order to be effective at their work.</span></li><br /> <li style="font-weight: 400;"><span style="font-weight: 400;">Inform everyone on the list and get them excited about the new team member. Tell them about the new team member, just enough to spark curiosity.</span></li><br /></ol><br /><h3><span style="font-weight: 400;">Go!</span></h3><br /><span style="font-weight: 400;">When the new team member joins, execute your first-day plan. Have a fun introduction session with the team and management. Make the new team member comfortable.</span><br /><br /><span style="font-weight: 400;">Over the next few days, introduce them to the department or the company (depending on the size of the company). Introduce them to the initial checklist you prepared. Let them know it is for them to just get started and use as an initial tool, and the team is ready to help.</span><br /><h4><span style="font-weight: 400;">The onboarding canvas tool</span></h4><br /><span style="font-weight: 400;">After few days and within the first couple of weeks, introduce the new team member to a collaborative tool such as the onboarding canvas. The onboarding canvas is derived from </span><a href="http://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">Spotify's adaptation</span></a><span style="font-weight: 400;"> of the </span><a href="http://www-personal.umich.edu/~mrother/Homepage.html" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">Toyota Kata</span></a><span style="font-weight: 400;">. </span><br /><p style="text-align: center;"><i></i></p><div class="separator" style="clear: both; text-align: center;"><i><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP6Gmc7qSmWYlMd8w7M5gF-qr0RaDxovil-tfwJPXbq6CxEbmk3jMZf1AHZPrjL_TRNgL1NH8QKfMTpmS9xSrDHj5s_HfNa_l_yT4IqT6qSTr-RQWrrmhEcRf6fJw8NmwU4Txgf9Wk3VQ/s1030/Onboarding-Canvas-w1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1030" data-original-width="1030" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP6Gmc7qSmWYlMd8w7M5gF-qr0RaDxovil-tfwJPXbq6CxEbmk3jMZf1AHZPrjL_TRNgL1NH8QKfMTpmS9xSrDHj5s_HfNa_l_yT4IqT6qSTr-RQWrrmhEcRf6fJw8NmwU4Txgf9Wk3VQ/s320/Onboarding-Canvas-w1.jpg" /></a></i></div><i><br /><span style="font-weight: 400;"><br />Onboarding Canvas</span></i><p></p><br /><br /><h4><span style="font-weight: 400;">Using the Onboarding Canvas</span></h4><br /><span style="font-weight: 400;">Collaborate with the new team member to fill the onboarding canvas and iterate regularly with the new team member. I suggest that iterating every two weeks, to begin with. Based on the experience and the needs of the new employee, tweak the frequency of iteration. Iterate more frequently if there are lots of things to discover, or slower if there are fewer. Being agile, try to break things down into smaller chunks in order to obtain frequent feedback. This really helps when getting started!</span><br /><br /><span style="font-weight: 400;">It is interesting to see how the roles of the new team member and the old team members evolve during this process. For example, while the old team members continue to play a vital role, they transition from being drivers to being supporters and consultants. The new team member quickly hops onto the driver’s seat, knowing well that there will be support and guidance when needed.<br /></span><br /><br />Read <a href="http://www.agilecandor.com/?p=239">Make onboarding fun with Onboarding Canvas!</a> for more details on using the onboarding canvas.<br /><h3><span style="font-weight: 400;">Done!</span></h3><br /><span style="font-weight: 400;">Alongboarding is complete when the new team member and the team both agree that it has been done to a sufficient degree. When that happens, the team should find itself closer and stronger compared to when they started. Although the duration and the number of iterations that you choose depend on your situation and needs, one way of using the canvas is to use it for six months, gradually reducing the frequency of iterations over the period.</span><br /><h3><span style="font-weight: 400;">Summary</span></h3><br /><i><span style="font-weight: 400;">Alongboarding</span></i><span style="font-weight: 400;"> is about making the partnership between the new employee and the team “real”.</span><br /><br /><span style="font-weight: 400;">It makes it easier for both the team and the new employee to adapt to the changes and understand each other better. The </span><i><span style="font-weight: 400;">Onboarding Canvas</span></i><span style="font-weight: 400;"> is a nice tool that can be used to promote conversation and discovery. </span><i><span style="font-weight: 400;">Alongboarding</span></i><span style="font-weight: 400;"> in combination with the </span><i><span style="font-weight: 400;">Onboarding Canvas</span></i><span style="font-weight: 400;"> makes the whole onboarding experience agile. The experience continuously evolves, improves and delivers what is important to its users quickly and incrementally. It is collaborative and is easy to understand. It makes onboarding fun and builds trust amongst the team members. </span><br /><br /><span style="font-weight: 400;">I am interested in hearing your thoughts and learning about how it goes for you when you try it!</span><br /><br /> <br /><br /><span style="color: grey;"><b><i>Credits and References</i></b></span><br /><ul><br /> <li><span style="color: grey;"><i><span style="font-weight: 400;">Thanks to my onboarding experience at </span></i></span><a href="https://www.appfolio.com/" rel="noopener noreferrer" target="_blank"><i><span style="font-weight: 400;">AppFolio</span></i></a><span style="color: grey;"><i><span style="font-weight: 400;"> and the wisdom of these coaches, I can say that this method works. Thanks, Ellie Thomas, Heidi Helfand, Jennifer Payne, Paul Tevis and Valerie Clarke!</span></i></span></li><br /> <li><i><span style="font-weight: 400;"><a href="http://blog.crisp.se/author/jimmyjanlen" rel="noopener noreferrer" target="_blank">Jimmy Janlén</a></span></i><span style="color: grey;"><i><span style="font-weight: 400;">:</span></i><i><span style="font-weight: 400;"> </span></i></span><a href="http://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata" rel="noopener noreferrer" target="_blank"><i><span style="font-weight: 400;">Improvement Theme – Simple and practical Toyota Kata</span></i></a></li><br /> <li><span style="color: grey;"><i><span style="font-weight: 400;">Mike Rother: </span></i></span><a href="http://www-personal.umich.edu/~mrother/Homepage.html" rel="noopener noreferrer" target="_blank"><i><span style="font-weight: 400;">Toyota Kata</span></i></a><span style="color: grey;"><i><span style="font-weight: 400;">.</span></i></span></li><br /> <li><span style="color: grey;"><em><span style="font-weight: 400;">The Center for Nonviolent Communication: </span></em></span><em><a href="https://www.cnvc.org/Training/needs-inventory" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">The needs inventory</span></a></em><span style="color: grey;"><em><span style="font-weight: 400;">.</span></em></span></li><br /> <li><span style="color: grey;"><em><span style="font-weight: 400;">Wikipedia: </span></em></span><em><a href="https://en.wikipedia.org/wiki/Onboarding" rel="noopener noreferrer" target="_blank"><span style="font-weight: 400;">onboarding</span></a></em><span style="color: grey;"><em><span style="font-weight: 400;">.</span></em></span></li><br /> <li><em><a href="http://www.agilecandor.com/?p=239">Make onboarding fun with Onboarding Canvas!</a></em></li><br /></ul>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com1tag:blogger.com,1999:blog-5094680508146116163.post-10557300637487520752016-04-11T13:55:00.000-07:002021-03-20T12:31:08.300-07:00#agilefails: 10 Roads to Hell<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQbsTSyPcA_FoOrWkRzVhn0tqfIBKtL7X8divz4Vbp9guF_R7QFFzBQtPvs3UCScg-PryUmg-015ItY2uKrlCZnlICnvcrHpP3CjbkUAToKmZ8bInsRKmsnWQiYdNbQZcXV1hJGvzsjtU/s1280/firefighters-1147795_1280.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="#agilefails - Firefighting is never easy!" border="0" data-original-height="849" data-original-width="1280" height="424" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQbsTSyPcA_FoOrWkRzVhn0tqfIBKtL7X8divz4Vbp9guF_R7QFFzBQtPvs3UCScg-PryUmg-015ItY2uKrlCZnlICnvcrHpP3CjbkUAToKmZ8bInsRKmsnWQiYdNbQZcXV1hJGvzsjtU/w640-h424/firefighters-1147795_1280.jpg" width="640" /></a></div><br /><br />Dealing with tough situations in product delivery is always a challenge!<br /><br />There are usually multiple ways of dousing flames and fixing situations. Unfortunately for us, when we are in the thick of things, we often get carried away and adopt the first solution that comes to mind. They say that the road to hell is paved with good intentions!<br /><br />Over the last few years, I have come to believe that best solutions are ones that balance our short-term needs with our long-term view.<br /><br />I present <strong>#agilefails</strong>. These are examples of partial fixes that do not address the root cause of our problems. [bctt tweet="While each #agilefail may help relieve an immediate pain, it is insufficient in the long run." username="sawhney_rahul"]<br /><br />This list will likely grow and evolve as I continue to learn and discover.<br /><br /><strong><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzHZl-XGTkSe8b3KwSH2_UCPtJMvlOM7YbP6XN2XUQci4yvh7v-IERKTPNdUTZKcTyeH9EIKtVIgrUSr75sD4SbaAtnCZfE52g-tB-v8vNzS-NmBazAVPRWL51W8aVI6lMkEV_7IfrOzk/s2028/Spiral-2-1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="591" data-original-width="2028" height="186" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzHZl-XGTkSe8b3KwSH2_UCPtJMvlOM7YbP6XN2XUQci4yvh7v-IERKTPNdUTZKcTyeH9EIKtVIgrUSr75sD4SbaAtnCZfE52g-tB-v8vNzS-NmBazAVPRWL51W8aVI6lMkEV_7IfrOzk/w640-h186/Spiral-2-1.jpg" width="640" /></a></div><br /><br />#1:</strong> A long-running project is getting delayed. We are struggling to deliver based on our estimates. #agilefail - Let's add new team members!<br /><br /><strong>#2:</strong> A senior leader wants something new immediately. #agilefail - No conversation needed. Some of us must immediately start working on this new "opportunity".<br /><br /><strong>#3:</strong> Team is getting too big to manage. #agilefail - Let us create multiple component teams (with multiple dependencies) to manage them better.<br /><br /><strong>#4:</strong> Too many meetings are eating up our productive time. #agilefail - First get rid of the retrospectives, then grooming, and eventually reduce stand-ups to few days a week.<br /><br /><strong>#5:</strong> Testers only want to test, developers only want to develop. #agilefail - That makes sense, it is their career path after all. It’s our duty to encourage that behavior.<br /><br /><strong>#6:</strong> Rockstar team member hoards knowledge and we are afraid of losing him/her. #agilefail - Ensure that our rock-star is happy and promoted, so that person does not leave.<br /><br /><strong>#7:</strong> Too many stakeholders want something delivered. #agilefail - Stop the conversation, do not commit anything as we are too busy. -OR- Commit to everything and still make everyone wait.<br /><br /><strong>#8:</strong> Not everyone understands the value of collaboration. #agilefail - Make our most expensive tech people as Scrum Masters.<br /><br /><strong>#9:</strong> There is a shortage of people with a particular skill-set in town. #agilefail - Training our teams will take too much time. Let us hire remote employees who will be experts. We will make them work like hell with multiple teams.<br /><br /><strong>#10:</strong> We have a tough delivery date for a big new project. #agilefail - There is no time!! Get coding ASAP and work weekends if needed! We can understand customer needs as long as each team knows its own part. There is no time to spend on process either. Teams can do whatever they want.<br /><br /><strong>My disclaimer:</strong> There is something to be said about what we can change and what we can't in our situation. We may find that a partial fix may be a step in the right direction and enable us to have a deeper conversation about fixing the root cause.<br /><br /><strong>What do you think?</strong> Have you faced any of these situations? What did you do, and what did you learn? What other #agilefails have you come across?<br /><br />Curious.<br /><br /><span style="font-size: xx-small;">Firefighters image courtesy: https://pixabay.com/en/firefighters-training-live-fire-1147795/</span>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-91102604592280056912015-12-22T06:53:00.000-08:002021-03-20T12:32:37.395-07:00Daily stand-up: 10 tips to energize & strengthen team focusHave you been in daily stand-up meetings that were not well run? Believe me, you are not alone if you visualize a bunch of headless chickens when you attend a badly run daily stand-up. So what can you do to improve the daily stand-up, other than pressing the reset button (which you should consider)?<br /><br /><span class="desc" contenteditable="true" id="snippet_meta">Here is my list of top tips to energize and strengthen a Scrum team's daily stand-up meeting</span>. These are not things must be done all the time, but general ideas that help. In other words, these are just tips that should help you identify patterns in your team, <strong>use them when practical and only with agreement from the team.</strong> Some of these tips that apply to all meetings and others are specific to stand-ups:<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTSN2L20KbrWOzllp0nzu1of_AmN0Rdhzl_fodtwFoF65X8PycR0lObT2CcpjWXdl5Nuy8Q7enBLAJ2qDtvo5NXuGZKMwtO4nvLfc0udKg4iL4LkPBGz_nQR9epa2YWz5MubIciJOMAIw/s1707/StandupInfographic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1280" data-original-width="1707" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTSN2L20KbrWOzllp0nzu1of_AmN0Rdhzl_fodtwFoF65X8PycR0lObT2CcpjWXdl5Nuy8Q7enBLAJ2qDtvo5NXuGZKMwtO4nvLfc0udKg4iL4LkPBGz_nQR9epa2YWz5MubIciJOMAIw/w640-h480/StandupInfographic.jpg" width="640" /></a></div><br /><br /><ol><br /> <li><strong>Actively find and remove impediments</strong> - Many team members think meetings are a waste of time. Usually, this is because they find doing their own work more meaningful and meetings take them away. If they do not understand what's in it for them, team members are likely to be less attentive. One way to change that is by showing results. If you are the Scrum master, strike short conversations to help identify the impediments. Ask the team what is impeding their progress, who can help remove the impediments and when. By helping to identify (and thereby remove) impediments, your team is guaranteed to improve its performance and gain more confidence.</li><br /> <li><strong>Clarify purpose and rules, but keep it informal</strong> - It is hard for team members to be attentive and participate when they don't know what the meeting is really about. I urge you to beyond asking the team members to answer the three questions of a daily stand-up - I urge to let them know how important it is to sync up and ask each other for help and provide help. If your stand-ups are mechanical and just revolve around Scrum master collecting status updates from each individual, clearly your team does not understand why they need to attend the stand-up.</li><br /> <li><strong>A short daily stand-up</strong> - Here is another extreme that some teams might wind up into. In their love and passion for talking, they ignore the 15-minute boundary of the stand-up and forget that it is a short sync point in a day, where everyone is getting visibility and highlighting impediments and asking/offering help. A stand-up is not an endless chat, and extensive discussions should happen elsewhere.</li><br /> <li><strong>Keep chairs away</strong> - Do you have a stand-up in your work area or in a meeting room, where everyone has to come in and find a chair? Do you have a stand-up standing up or sitting down? All of this makes a difference. Standing up helps people to get back to work and keep conversations short. Getting in a room to have a stand-up means more time lost in getting into and finding a chair in the room.</li><br /> <li><strong>All pigs must attend</strong> - What happens when a team member does not join the stand-up? The team as a whole loses visibility into the progress and challenges of that team member. The team member loses the ability to ask for the help of the whole team. The team member also loses the opportunity to help other team members who are facing difficult tasks.</li><br /> <li><strong>Ensure remote participants get value</strong> - Special handling is required for remote participants. Since they are remote, this is their time to get a direct sense of what is happening. Remote attendees are likely to use an online collaboration tool such as GoToMeeting or Skype. Ensure that their audio and video (if you use a camera) works. If there are problems, that can derail the entire meeting. When there are problems ensure they are addressed promptly and prevented from occurring again in later meetings.</li><br /> <li><strong>Ensure new team members get up to speed fast</strong> - Often new team members may join the team. While new team members bring in new knowledge, they could also lag behind in their understanding of how the team operates. While most new team members learn to adapt, it can be harder for some and at times disruptive. Assuming your stand-ups are running well, pay special attention to needs of new team members and identify what they bring to the party. Consider if they need training. Make an effort to prepare them to participate in the stand-ups and you will usually be fine.</li><br /> <li><strong>Use physical or virtual boards</strong> - I have noticed that teams that review a stand-up board with a sprint backlog get better visibility on progress. Personally, I prefer that the board with physical - with real stickies and real wall. This encourages collaborative nature of the stand-up and allows anyone to move around the stickies. Sometimes that is not possible - For example when a team member is remote. In that case, using a tool like JIRA, VersionOne, Rally etc. is an alternative.</li><br /> <li><strong>Supplement with solver sessions</strong> - This can be tricky and can take a good amount of skill. In order to keep the meeting short and keep the team focused, the Scrum master may be tempted to shut down the conversation. At the same time, the conversation may be really important for the team to get on the same page. You may have to choose what to do depending on the conversation. Intervene when necessary and help setting up solver sessions to go into details of the issue that requires a deep dive.</li><br /> <li><strong>Inform in advance</strong> (if you miss, but miss rarely) - At times there are situations when team members can't avoid skipping a stand-up. There is no good solution to this. In such situations, I recommend working with the team on how they can inform each other about their daily updates and plans, in advance if possible.</li><br /></ol><br /> <br /><br />I hope some of these tips will help teams run better daily stand-up meetings. As always, I am interested in learning more. So if you have other tips to share, I would love to hear about them - leave a comment! And I will inspect and adapt.<br /><br />You may also be interested in:<br /><ul><br /> <li><a href="http://www.extremeprogramming.org/rules/standupmeeting.html" rel="noopener noreferrer" target="_blank">This 15-Minute Meeting Might Be the Only One You Need</a></li><br /> <li><a href="http://www.thinslices.com/scrum-ceremonies/" rel="noopener noreferrer" target="_blank">Scrum Ceremonies. It’s Time to Dance!</a></li><br /> <li><a href="http://www.agilecandor.com/retrospectives-10-ideas-agile-teams/">Retrospectives: 10 ideas for agile teams</a></li><br /></ul>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-76181708703232736342015-11-22T08:20:00.000-08:002021-03-20T12:33:47.592-07:0010 valuable lessons for agile retrospectives<blockquote><i><b>"Today should always be better than yesterday"</b> - mother of Gabby Douglas, the first African American to win individual all-around gold and the first American to win gold in both the individual all-around and team competitions in gymnastics.</i><b></b></blockquote><br /><b>A retrospective</b> provides the opportunity for teams to get together and tweak "something" so they can achieve better results than before. Teams use retrospectives for <a href="http://blog.gdinwiddie.com/2012/05/30/goals-of-a-retrospective/" rel="noopener noreferrer" target="_blank">joint learning, making a decision, choosing an action or strengthening a common bond</a>. In Scrum, retrospectives are held at the end of each sprint. Kanban is non-prescriptive about retrospectives, but most kanban teams end up doing retrospectives at a regular interval or as-needed basis.<br /><br />Some teams resist the retrospectives and lose them entirely. Why does that happen and what is the impact? Well, that's another article for later.<br /><br />Here we look at the positive, and how agile teams use retrospectives to their advantage. This list is just a small subset of many possibilities on what agile teams can do in a retrospective!<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHT2mPs3OlbRk_ucXWXL3G-xg4eRZdfzEYxidAuuUrS7X4-GqmYzRYlPyFchp4guBKge0cHIGkC9n3zKjteKbvgU3TAuzlpGGLransXsCluAd4dn5pTEEznrfAtFUN1T1I6E2peu300I8/s1280/Retrospectives.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="10 valuable lessons for agile retrospectives" border="0" data-original-height="1280" data-original-width="720" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHT2mPs3OlbRk_ucXWXL3G-xg4eRZdfzEYxidAuuUrS7X4-GqmYzRYlPyFchp4guBKge0cHIGkC9n3zKjteKbvgU3TAuzlpGGLransXsCluAd4dn5pTEEznrfAtFUN1T1I6E2peu300I8/w360-h640/Retrospectives.png" width="360" /></a></div><br /><br /><ol><br /> <li><b><b>Discover team strengths, weaknesses and opportunities: </b></b>Retrospectives help team members discover what the team is doing well and where it can make improvements.</li><br /> <li><b>Raise the bar on team performance:</b> Based on the strengths and weaknesses, agile teams inspect and adapt. They either improves their performance or helps them adjust to new situations and stay on course.</li><br /> <li><b>Review data, important trends: </b>Scrum Masters and other team members may collect important data and trends and review with the team during the retrospective. The data can be a generic trend or related to a specific issue that the team would like to resolve or anything else relevant to the team. Looking at the data together usually produces new insights for all team members. It helps to find better ways to resolve the problem.</li><br /> <li><b>Prioritize problems that the team must address: </b>Teams usually identify multiple issues and areas of attention during the retrospective and then they narrow down to the most important ones for them to solve.</li><br /> <li><b>Solve difficult problems: </b>Sometimes<b> </b>teams may already know of a problem that must be solved. In retrospectives, teams may deploy various problem-solving techniques, such as root cause analysis or five whys, or even discussing the results of an A3 process together.</li><br /> <li><b>Ask for organizational and leadership support:</b> Depending on the organization, some problems may be beyond the team's sphere of influence. By prioritizing and discussing possible solutions, the teams can make a case for change that would impact them positively.</li><br /> <li><b>Cheer, appreciate, express gratitude:</b> Retrospective can be a forum to celebrate success on completion of a hard initiative or a specific activity that the team undertook. Teams can utilize retrospectives to bond together and appreciate each others' strengths and contributions and thank each other for critical help in completing or making progress towards a goal.</li><br /> <li><b>Support each other: </b>A healthy team harnesses and extends ideas from its members. Retrospectives are an opportunity to strengthen some of the beliefs and the ideas that team members want to adopt. In that process team members support each other and make progress on what they think is important.</li><br /> <li><b>Challenge each other: </b>Not only are the retrospectives meant for supporting ideas, they are also meant for challenging ideas. Challenging ideas helps the team narrow down to one or few ideas that the team wants to try.</li><br /> <li><b>Experiment:</b> Teams, Scrum Masters, and facilitators can and should experiment with how they conduct retrospectives. They can vary the format, agenda, and results they want from the retrospective. They may also just use the retrospective to have a conversation to make changes that are needed.</li><br /></ol><br />Lastly, even if you are a Scrum team, please do not wait for a sprint-end retrospective to have a conversation with your team about important issues that you need to solve.<br /><br />Related:<br /><ul><br /> <li><br /><div><a href="http://blog.gdinwiddie.com/2012/05/30/goals-of-a-retrospective/" rel="noopener noreferrer" target="_blank">Goals of a Retrospective</a></div></li><br /> <li><a href="http://retrospectivewiki.org/" rel="noopener noreferrer" target="_blank">Agile Retrospective Resource Wiki</a></li><br /> <li><a href="https://www.mountaingoatsoftware.com/agile/scrum/sprint-retrospective" rel="noopener noreferrer" target="_blank">Sprint retrospectives</a></li><br /> <li><a href="http://www.funretrospectives.com/prime-directive/" rel="noopener noreferrer" target="_blank">Retrospectives: Prime directive </a></li><br /> <li><a href="http://www.agilecandor.com/?p=11">There's hope (usually!)</a></li><br /> <li><a href="http://www.amazon.com/gp/product/0977616649/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0977616649&linkCode=as2&tag=wwwcookingyou-20&linkId=MHQENV42QEXB75G7" rel="nofollow noopener noreferrer" target="_blank">Agile Retrospectives: Making Good Teams Great, by Esther Derby, Diana Larsen</a><img alt="" border="0" height="1" src="http://ir-na.amazon-adsystem.com/e/ir?t=wwwcookingyou-20&l=as2&o=1&a=0977616649" style="border: none; margin: 0px;" width="1" /></li><br /></ul><br /><h3></h3>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com2tag:blogger.com,1999:blog-5094680508146116163.post-28645046054543817482015-11-15T20:35:00.000-08:002021-03-20T12:47:31.370-07:00Rough notes: Misunderstood agile practices<span style="font-family: "Times New Roman",serif; font-size: 12pt; line-height: 107%; mso-ansi-language: EN-US; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;">Let us assume management and team have some experience with agile but they only understand parts of it (such as iterative delivery, sprint ceremonies etc.). Have you faced such situations? Which practice(s) and concept(s) did you strive to adopt but were challenged? what tools did you use for influencing the outcomes?</span><br /><span style="font-family: "Times New Roman",serif; font-size: 12pt; line-height: 107%; mso-ansi-language: EN-US; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;"> </span><br /><br /><br />Here are some highlights from a <a href="https://www.linkedin.com/grp/post/37631-6068041879511908355#commentID_6071873357291208704" target="_blank">LinkedIn discussion</a> I started about misunderstood agile practices.<br /><span style="font-family: "Times New Roman",serif; font-size: 12pt; line-height: 107%; mso-ansi-language: EN-US; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US;"></span><br />* In many "traditional" companies agile is seen as a new set of controls to get work done. Old roles are re-labeled.<br /><br />* Many companies think that they can purchase agile as product also if they have few certified SM/PO on pay roll, company is agile.<br /><br />* Misconception: Equating testing with quality improvement. Quality needs to be designed in from the get go.<br /><br />* Try this: Making metrics visible. Nobody can argue with truths, and the truth is a strong motivator of change in group dynamics.<br /><br />* Conducting honest retrospectives over many sprints is often neglected.<br /><br />* The biggest mistake that people make is thinking that Agile is a process, and if you do the process, you'll be successful.<br /><br />* Agile practices could be perfectly implemented but with inappropriate mindset and intention, then practices perfectly implemented in physical and visible shapes will all always be misunderstood.<br /><br />* Misunderstanding Being Agile vs. Doing Agile: Most people don’t understand the difference between Being and Doing. Agile isn’t something you do. It’s something you are.<br /><br />* Misunderstanding the proper amount of documentation needed. Reading "Working software over Documentation and Processes" and forgetting the final line of the manifesto, "Although we value the things on the right, we value the things on the left more".<br /><br />* The problem is with the mindset. A mindset change is more difficult of a change and involves coaching/training/teaching and importantly discussions around what Agile is to the team/department/company.<br /><br />* Many chickens do not understand the "doing" vs "being" agile.<br /><br />* Misunderstanding: Many organizations associate agile with tools...like "I am using Jira / Rally / TFS /(any other tool you can think of) and still not able to get the benefits of agile. Looks like agile doesn't work for us"!!!!<br /><br />* Transparency does not mean micromanagement.<br /><br />* Misunderstanding: Dysfunctional Waterfall is the same as Successful Waterfall.<br /><br />* Misunderstanding: If I cut my big traditional programme of x years without any reliable progress indicator into small iterations, that I can reasonable expect precise forecasts / commitments and then still get all the benefits of agile.<br /><br />* Misunderstanding: Agile methodology is not suitable for products which take multiple years to build.<br /><br />* Misconception: "Agile is for those who are not disciplined enough for processes", i.e. "You can improve Agile by introducing more rigid processes."<br /><br />* Try this: Look at your dev / test / staging infrastructure and automation around that. And your engineering skills and practices.<br /><br />* Misunderstanding: Scrum ceremonies often misunderstood and poorly done, but yes Daily Standup especially. As it returns every day.<br /><br />* Misunderstanding: "We create user stories ñ try to complete them in two weeks" so we follow agile ...<br /><br />* Misunderstandings: Originally, there are things like "I can't break down my work that small." Or "our testers are used to being at the end, we can't include them in our current sprints." And the misconceptions just move on down the line as you transform the teams.<br /><br />* Quote: Wisdom begins when we discover the difference between "That makes no sense" and "I don't understand". --Mary Doria Russell<br /><br />* My favorite takeaway:<b> It is far better to move ahead with a wealth of misconceptions and the personal and organizational intent to continuously improve than to try and identify and correct the misconceptions first.</b>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-6802583151290805642015-11-08T19:56:00.000-08:002021-03-20T08:22:06.541-07:00Agile managers: Are you listening?<div style="clear: both; text-align: left;">I keep running into situations where managers, with all their good intentions, either misinterpret, ignore, or fail to understand certain agile concepts due to various reasons. Shortcuts provide them immediate relief the long term pain typically aggravates. This impacts not just the outcomes, but also the team and the managers in ways that are usually not positive.</div><br/><strong>Are you a manager?</strong> This is for you...<br/><ol><br/> <li><b><span style="font-size: large;">Start right</span></b>, because if you don't you will put the entire project or initiative in jeopardy. Managing expectations is the key. If your voice is not being heard by higher-ups, do not be a weakling and get help. It could be someone with more influence or with more experience or perhaps a mentor or a coach. Ask yourself - who can help you make a convincing argument and even argue on your behalf? Engaging higher ups is not sufficient. Get your team to appreciate why starting right is in their own interest. Ally with the team.</li><br/> <li><b><span style="font-size: large;">Adapt or Die</span></b>. If you don't learn from mistakes you will find it hard to survive. This is applicable for you not just as an individual but also for your team. Those who do not learn from their mistakes and from each other, keep running fire-drills. If using Scrum, lack of learning will manifest itself as smells and Scrum-butts. You might even give up parts of Scrum, abandon it altogether, or start using your own "easy-Kanban" method without applying WIP limits or even visualizing their workflow. Are you a leader of such a team or teams? Why do you think this is happening?</li><br/> <li><b><span style="font-size: large;">Be transparent</span></b>. At times there may seem to be a tendency and perhaps even an incentive not to be transparent about your project and team. There could be many reasons for this situation, organization-created or self-created or just fabricated from fear. When you look into the reasons, think about what is best for you, best for your team, best for your organization and best for the customer - ideally, all the four should have the same answer. If not, dive deeper and ask why is there a difference? Can you do something? If you can't do anything about it, are you at the right place doing the right job?</li><br/> <li><span style="font-size: large;"><b>Promote collaboration, simplicity, and excellence</b></span>. Agile principles talk about collaboration, simplicity and emphasize technical excellence. There is usually nothing more powerful than collaborating to deliver successful outcomes, in small chunks, along with technical excellence, that motivates a strong development team. As a manager, you carry a ton of influence and responsibility to make this happen.</li><br/> <li><b><span style="font-size: large;">Deliver customer value and team happiness</span></b>. You have demonstrated your success as a manager when your team is delivering functionality that makes customers happy, it is building-in quality into the product, and is proud of its accomplishments. <strong>The process may be useful but it is not the goal.</strong></li><br/></ol><br/>Good luck!Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-86143801405092593762015-10-20T11:58:00.000-07:002021-03-20T08:22:06.597-07:00How to increase velocity? No silver bullet, but it can be done<h3>Ugh... increase Velocity? That question again?</h3><br/>In a discussion forum, I came across this comment that "Velocity is an awful term and one that is often weaponized like it has been in this thread by asking how to get more. It's the wrong question because the goal is to become predictable much more so than faster."<br/><br/>I do not agree that velocity is an awful term, but I do agree that it is often misused (and even weaponized). If you intend to use velocity the right way and are interested in using it as a tool to understand and improve your work outcomes, this post is dedicated to you.<br/><br/>I would like to note that some of my friends are passionate about #noestimate. Whether you go that route or not, is your choice. The important thing is that is the team performing or worrying about numbers and metrics. If velocity discussions are weighing down the team, that is usually a sign of a different problem.<br/><br/>As you go through this post, keep in mind that increasing velocity may not be your real and only problem, and should definitely not be your main goal.<br/><div style="clear: both; text-align: center;"></div><br/><h4>Addressing the "Real Slim Shady"...</h4><br/><h4><span style="font-weight: normal;">If you want to address the issue genuinely please understand there is never really an end. </span></h4><br/><span style="font-weight: normal;">If the team is rapidly delivering customer value, communicating well and learning from its experience you may only have limited leverage on what the team itself can do. The team may need support from its ecosystem to take it to the next level. At the same time, there will still certainly be things that can team can do to make improvements. and is improving velocity the end goal? Or is it delivering customer value rapidly?</span><br/><span style="font-weight: normal;">Let's address that.</span><br/><br/> <br/><h4>Step 1. Who is asking?</h4><br/>Before you go any further it is important to understand who wants to increase the velocity. Many a time someone higher up in the food chain may want to know how you will improve the velocity. It may also be a software developer on the team, the whole team, the product owner or the scrum master (is that you?) who is interested. Or it may be a stakeholder, project sponsor or anyone else as well. Understanding who is concerned about improvement in team's velocity can help you in several ways in the steps that follow.<br/><h4>Step 2. Why are they asking - their motivation?</h4><br/>Before you jump into a solution, identify why they are asking the team to increase its velocity. What's in it for them (who want the team to improve)? As you dig deep into the reason for asking, you will likely discover the intent (good, bad, helpful, unhelpful) of the person asking the question. You will become sensitive to their needs and discover their situation. Are they interested in improving communications and flow of value or do they have a personal gain in mind by highlighting the problem? Answering why will help not just with framing the response better but also with taking more informed actions. Whatever the reason is, think about how that can help you drive improvements.<br/><h4>Step 3. Draw insights - Where are the problems, what are the solutions?</h4><br/>Based on your study of your context, would it be fair to say there are potential opportunities for improvement? Where could the team do better?<br/><br/>Imagine a team delivering really really fast but the customers are not responding favorably. Could it be the lack of quality or delivery of functionality that customers do not need? In either case, increasing velocity may not be the best solution. We need to think smarter.<br/><br/>Try these questions first:<br/><ol><br/> <li>Is the team delivering new features and improvements frequently?</li><br/> <li>How are customers reacting to the product deliveries and latest features?</li><br/> <li>Is the team generally enjoying their work and having fun?</li><br/></ol><br/>If you spot problems while answering these questions, search deeper. Here are just a few examples of what you could explore.<br/><h5>People questions:</h5><br/><ul><br/> <li>Do measures such as velocity drive positive behaviors in your organization? If not what can be done to fix that situation?</li><br/> <li>Are the roles well defined? Is there sufficient empowerment? Are the roles of PO, SM, and Development team clearly understood?</li><br/> <li>How is communication between the team members?</li><br/> <li>How strong are the leaders of your team, project and the organization?</li><br/></ul><br/> <br/><h5>Process questions:</h5><br/><ul><br/> <li>How do you assess progress towards an important goal? Do you have an objective method?</li><br/> <li>Are team members working on multiple diverging goals and functionalities and have high work in progress?</li><br/> <li>How are releases managed and rolled out - small chunks or big rocks?</li><br/> <li>What is the team doing to continuously learn from its journey?</li><br/> <li>How are (Scrum) meetings running?</li><br/></ul><br/> <br/><h5>Technology questions:</h5><br/><ul><br/> <li>How is the team doing on the account of technical debt?</li><br/> <li>Is there sufficient test automation and continuous integration?</li><br/> <li>How is your quality? Do you have a huge bug backlog?</li><br/></ul><br/>Draw insights together with the entire team to understand all perspectives and see what can be done. Dig into the backlog, measurements that the team thinks are relevant, such as velocity, cycle time, defect trends, automation, build failure rate etc. Looking for problems, and asking why over and over again, should give you new insights on what can be done.<br/><br/>Shortlist a few experiments to try out.<br/><h4></h4><br/><h4>Step 4. Sell, Try, Feedback, Repeat (Go to step 1)!</h4><br/>As you go through this exercise, you may come up with a range of solution(s). Some solutions may require senior management intervention, others may need more involvement from the team. Channel the conversations around the solutions, convince the stakeholders to try them out. Clarify how you will be reviewing the outcome - set a time-frame for that. Try the solution and get more feedback!<br/><br/>You may have to repeat these steps several times, to continually get the results you are hoping for (including but not limited to an improved velocity, as that may not be the real goal you are after).<br/><br/>Good luck!Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-90197014032295878212015-10-14T22:14:00.000-07:002021-03-20T12:35:04.282-07:00There's hope (usually!)...Imagine things are going completely out of control; ownership and accountability are minimal; there is little willingness to collaborate and not enough leadership to make it happen. You are down with dismay and disbelief at how things are going... feeling blue and nothing seems to move despite your best effort? Imagine yourself stuck in the moment unable to get out!<br /><br />We wish never to be confronted with a situation like that. Nevertheless, stuff happens, at times all we can do is think, and think hard what we should do but answers don't come easy or fast. How can we help change the situation for the better? That is the agile mindset isn't it - inspect and adapt until we find an answer?<br /><div style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirkpF5HGak0U6gYgTOLscuNH6MflGBzZJzOOG73nmbhPo-4QWPEkLQxWi-CNl1N4iKvvEicX9-yUlAySil-FXK7m9tfDjgTvzO2E2OQgqt3T2xJ2tiAJQ6jwh6wiayaAGAVsMCDBNyIfQ/s640/direction.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="426" data-original-width="640" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirkpF5HGak0U6gYgTOLscuNH6MflGBzZJzOOG73nmbhPo-4QWPEkLQxWi-CNl1N4iKvvEicX9-yUlAySil-FXK7m9tfDjgTvzO2E2OQgqt3T2xJ2tiAJQ6jwh6wiayaAGAVsMCDBNyIfQ/w640-h426/direction.jpg" width="640" /></a></div><br /><br /></div><br /> <br /><h3>What to do?</h3><br /><h3>Should you stay hopeful or quit in despair!?</h3><br />I hate to say it, quitting could be an option if you are desperate. It could work in the short term and give you relief, but what would you achieve, what would you solve by quitting? Why not let someone else deal with the mess? Quitting is usually the easy way out, though not always the best.<br /><br />Why should you care? Before you decide whether to quit or to persevere, try answering these questions:<br /><ul><br /> <li>Would you learn something new that would prepare you for even greater challenges if you continued to persist instead of quitting?</li><br /> <li>Would you get a similar opportunity again... an opportunity to be a part of the solution to a very big or complex problem?</li><br /> <li>Could this be an avenue for you develop and practicing your skills in a particular area that you really want to learn?</li><br /> <li>How will the decision impact the organization that you work for, and your colleagues?</li><br /> <li>What will make you happy? What about your family and your friends?</li><br /></ul><br />I think:<br /><ul><br /> <li>If you are a kind of person who gets a kick out of bringing positive changes, you will likely enjoy persisting. Things usually change, and although they sometimes change for the worse, but they usually (eventually) change for the better.</li><br /> <li>If you enjoy learning, you will likely want to try and persist longer. You will also try to experiment with options you have not tried before and there is god chance you will succeed when others see value.. and they eventually will.</li><br /> <li>If you are very competitive (and perhaps driven by how fast you rise in your career charts!), you will likely calculate the risk/reward possibility around your situation and decide accordingly.</li><br /></ul><br /><h3></h3><h3> In short...</h3><br />Whatever you do depends on a lot on your situation, and the kind of challenges you are built for - your strengths, weaknesses, values and motivations. Give it a thought, introspect and make your choice. Good luck!<br /><br /><span style="font-size: xx-small;">Image sources:<br /><a href="https://pixabay.com/en/alone-being-alone-archetype-513525/">https://pixabay.com/en/alone-being-alone-archetype-513525/<br />https://pixabay.com/en/directory-signposts-hope-466935/<br /></a></span>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-57418135567536214932015-05-30T12:24:00.000-07:002021-03-20T08:22:06.713-07:00Why plan? A note to self..Would life be easier if we did not have to think about planning? Let's face it, whether it is about running our day to day routine or even something as simple as paying a visit to the neighborhood grocery store there is planning involved. Imagine taking a vacation without planning where you will go, what you will do while you are there, how long will stay and what you need to bring with you. Or imagine not thinking about how much you need to earn, to save and to invest to meet your worldly needs.. Well lets just keep those worries aside for a few minutes shall we and think about how planning can actually help! Yes that's right, no matter how much burdensome it might sound, <i>planning can help</i>.<br/><h3><b>What is planning?</b></h3><br/>The simplest definition of planning that I have come across is "decide on and arrange in advance". I like this because this definition is light, it does not say how much detail we need to plan in, but an important thing that it does say is that planning happens in advance.<br/><h3><b>Why plan? </b></h3><br/>There are many reasons why we plan. Our limited information about the future and vision of what we want to do with that information in order to achieve a specific objective gives us an opportunity to play with creative alternatives and paths to get there. Applying constraints helps us narrow down our search of solutions, breaking them down into chunks or steps that are (hopefully) easy to understand and sequence as necessary. When steps and solutions are not known we put on our experimentation hats and navigate our way to discovering the possibilities.<br/><h3>Use the plan as a defense strategy</h3><br/>So what should I tell my teams when they get planning? What are the things I need to keep in mind but don't come easy, specially with Scrum? In my note to self, I include the following.<br/><h4>Plan just in time, and just enough..</h4><br/>Plan early but not too early. Have a high level roadmap that (can change and) tells the team the path we will take if things went all-right. Planning too much too soon could mean a lot of wasted effort and repetition. Planning too little could mean little predictability in outcomes for initiatives that span multiple sprints. So lets groom our backlog stories and have them ready for a few (may be two to four) sprints to come. Lets find that right balance for our team where Sprint planning sessions do not become painful and burdensome.<br/><h4>Plan based on data..</h4><br/>More often than note, teams are asked to meet an "aggressive targets". In other words, there is a huge tendency to ask for deliveries tied to dates without understanding scope and effort involved. These dates are usually based on business constraints and are tight (more often than not). So, organizations and teams find themselves in situations where teams are unable to deliver as some say - "on time" and "within budget". Lets avoid that for our team through scientific and consistent use of measures such as velocity and cycle time. Lets make forecasts based on data so that business understands our non-trivial effort and can make realistic, prudent decisions on scope and priority.<br/><h4>Maintain discipline, Estimate or #NoEstimate..</h4><br/>There is much debate on whether to do estimates or not. What seems more important to me than that debate is to agree on an approach that works for our team and for your organization and follow it with discipline. When we estimate, lets spend little time estimating, after all estimates do not produce value for customer, working software hopefully does. Estimates are just that - "estimates", they are "not actuals".<br/><h4>High priority, High risk first..</h4><br/>What should the team work on first and what should it work on later? There are multiple factors that decide this, chief among them are dependencies, customer feedback and risk. The product owner plays an important role balancing all aspects while deciding the order so that team delivers value while making continuous progress. So lets keep in mind the problem we are trying to solve, and order our backlog on the basis of that. Lets identify those things that are not clear and run spikes. Lets reduce the risk early as early as we can, so that we do not embarrass ourselves in front of our stakeholders and customers when the time comes.<br/><h4>Minimize hand-offs, eliminate technical debt..</h4><br/>Lots of times, teams work with other teams to deliver an experience or functionality. Many times this needs dependency management, and back and forth discussions. This can lead to side effects such as reduced velocity, need for additional testing to retain quality, development of interfaces and/or APIs etc. When we get into such situations, lets find out if we can minimize dependencies through techniques like creating mockups, and integrate early and often. Let us ferociously automate testing and deployment (at all levels) so that we can identify and resolve issues quickly.<br/><h4>Plan often and monitor, welcome change..</h4><br/>Lastly, should planning be <i>one time</i>? Absolutely not! The team should be ready to embrace change as they get better insights into customer needs and potential solutions. Lets dispassionately accept new stories, reject old ones that are no longer useful and update ones that need to be updated. Once again, an active Product owner and Team partnership can make a big difference. It is not as important to stick to the initial plan as it is to fulfill needs of the customers.<br/><br/>Related reading:<br/><ul><br/> <li><a href="http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415" target="_blank">Agile estimating and planning</a>, Mike Cohn</li><br/> <li><a title="Permanent Link to The NoEstimates Hashtag" href="http://zuill.us/WoodyZuill/2013/05/17/the-noestimates-hashtag/" rel="bookmark">The NoEstimates Hashtag</a>, Woody Zuill</li><br/> <li><a class="l" href="http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf" data-ved="0ahUKEwjm25mooNnJAhVY4mMKHf1OCFIQjBAIIzAB">The Scrum Guide</a></li><br/></ul>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-27374053604766732152015-02-27T23:11:00.000-08:002021-03-20T08:22:06.769-07:00Want to be a Scrum Master - What is your motivation?<b>Thinking </b>about being a Scrum Master? Have you thought about:<br/>1. What is your motivation and do you think you are the right fit?<br/>2. Would you like it to be a career choice?<br/>3. What is in it for you? Is this role really attractive for you? What kind of growth are you looking for?<br/>4. What does this role mean to your organization?<br/><br/>If you have thought about any of these questions and chose to be a scrum master, you are among the few scrum masters I have come across, who had the chance to do so.<br/><br/>In many cases I have come across, being a scrum master has been a matter of chance, many times imposed, rather than a matter of choice. To me that is an indication of how much (lack of) thought we devote into our role in a team setting as we probably should. As a result, we have multiple cases of job done badly, the role being viewed as "just" an administrative role, or something so easy that "anyone" can do, etc.<br/><h2>Before you jump into the Scrum Master Role</h2><br/>Here I list a few things to think about when you are contemplating this role for yourself.<br/><br/>1. <span style="font-size: large;"><b>Start </b></span><strong>with motivation</strong>. Ask yourself why you want to be the scrum master, and what do you think you will achieve through that role. If you are a good scrum master, your services will be rewarded through your team's successes (or fast-fails, which should also be considered as successes). Highly successful teams will shine and through them, you will shine. Be aware that scrum master is only as strong as the team, so the primary job of the scrum master is to build a strong, learning team and actively sense and remove impediments that come its way.<br/><br/>2. <span style="font-size: large;"><b>Proud and Happy </b></span>Teams - Do you love that? Will you make it your mission to make your teams proud of the work they do and how they do it, so they can predictably meet their commitments to business, deliver quality output keeping technical debt under check? If you answered these questions as yes, you get full marks!<br/><br/>3. Are you looking for <span style="font-size: large;"><b>glory </b></span>for yourself or for the team(s) that you will serve? Can you be self-less in victory of your team's success, will you let them take the credit and can you teach them to learn from failures? Will your organization reward you if you served selflessly? Will your manager understand? If your answer to these questions is yes, you have hope.<br/><br/>4. Do you <span style="font-size: large;"><b>understand </b></span>Agile manifesto, Agile principles and do you subscribe to XP values of simplicity, communication, feedback, respect and Courage? If you answered yes, think again. If you answered yes again (and again), think about situations that could get you in trouble with stakeholders, management, and even the team that you might be serving. Would you be able to manage expectations and still help the teams succeed? Yes means you are in business!<br/><br/>5. Are you ready to <span style="font-size: large;"><b>learn, unlearn and learn again</b></span>? Different situations require different responses and solutions. Are you willing to experiment with different approaches, solutions and options with different team members, different teams, different projects, and different managers? Are you willing to engage with your audience and fail-fast, take responsibility for your team's decisions, actions and results (god or bad, specially bad ones)? Are you willing to be open, positively debate with your team, take responsibility of (poor) team decisions even if you disagreed with the team before the decision was made? Yes indicates you have it in you to be a great scrum master.<br/><br/>6. How does your <span style="font-size: large;"><b>organization</b> </span>view the role of a scrum master? Does it recognize this function as requiring special skills, training and coaching or is there a tendency that Scrum Master is a side-job that anyone with little time can do? If your organization recognizes the importance of this job, you are in luck and the probability of your success will increase dramatically! If it does not recognize it this way, your hard work, diligence and success will surely influence the organization, do not lose hope.<br/><br/><strong>Bottom line</strong>, if you want to be a good Scrum Master, wear your servant-leader hat, be well grounded and open to learn, and experiment your way to success.<br/><br/>Related reading:<br/><ul><br/> <li><a class="l" href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&sqi=2&ved=0ahUKEwjm25mooNnJAhVY4mMKHf1OCFIQjBAIIzAB&url=http%3A%2F%2Fwww.scrumguides.org%2Fdocs%2Fscrumguide%2Fv1%2Fscrum-guide-us.pdf&usg=AFQjCNHpo0uVXuTmZCtwkQwh_hjUsHin5A&sig2=9JTgbnHRilB1iMGHWuaH8w&bvm=bv.109910813,d.cGc" data-ved="0ahUKEwjm25mooNnJAhVY4mMKHf1OCFIQjBAIIzAB">The Scrum Guide</a></li><br/> <li><a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&sqi=2&ved=0ahUKEwiz6qTWotnJAhUJzGMKHaFaCA0QFgg2MAM&url=https%3A%2F%2Fwww.mountaingoatsoftware.com%2Fagile%2Fscrum%2Fscrummaster&usg=AFQjCNHBXvARJQOi8fXaytNLzGwCNq4Ryw&sig2=xDpdlXwGcKe1gCOTW4tKog&bvm=bv.109910813,d.cGc">ScrumMaster</a>, Mountain Goat Software</li><br/> <li><a href="http://www.scrumhub.com/what-does-a-scrum-master-do-all-day/">What Does A Scrum Master Do</a>?</li><br/></ul>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com2tag:blogger.com,1999:blog-5094680508146116163.post-71272511585868875142013-07-22T15:38:00.000-07:002021-03-20T08:22:06.860-07:00Can Agile Principles Help Run Successful Programs?<div dir="ltr" style="text-align: left;"><div style="text-align: left;"><div style="text-align: left;"><div style="margin-bottom: 0.0001pt;"><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">This article was first <a href="http://www.scrumalliance.org/community/articles/2013/july/can-agile-principles-help-run-successful-programs.aspx"><span style="color: blue;">published by Scrum Alliance</span></a> on July 22, 2013.</span></i><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><br />During the last few years, my view of how programs work has evolved. It has moved from viewing program management as traditional "old-school" handling of multiple projects and product portfolios (dry and boring) to seeing program management as a key to ensuring organization success that aligns the organization with its vision, strategy, and innovation. I think of program management as a crucial tool that makes an organization successful by pointing its entire energy and focus toward its most important initiatives and fulfilling its promise to customers, shareholders, and employees.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><b><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Why do organizations need programs?</span></b><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">"Programs are a group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually," according to PMI. What do organizations have to gain by investing in coordinating and controlling multiple projects as a program? This is similar to asking what value program management brings to an organization.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">A quick search on Google reveals various links on the topic. An </span><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><a href="http://smallbusiness.chron.com/benefits-program-management-4817.html"><span style="color: #ff6319; font-family: "Helvetica","sans-serif"; font-size: 10.0pt; text-decoration: none; text-underline: none;">article</span></a></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> at chron.com lists the following: comprehensive view, work toward strategic goals, consistency, cost savings. An </span><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><a href="http://www.ehow.com/list_6561766_benefits-program-management_.html"><span style="color: #ff6319; font-family: "Helvetica","sans-serif"; font-size: 10.0pt; text-decoration: none; text-underline: none;">article</span></a></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> at eHow.com lists supervision, organization, budgeting, funding, accountability, and delegation.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Program managers shepherd different teams and projects in the organization toward a common objective. These teams sometimes have different internal priorities, which can impact when and how they deliver their part of the program. Program managers help surface these issues and facilitate much-needed conversation around issues, risks, and mitigation to achieve a higher-level organizational goal (or a set of goals).</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style=" background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Streamlining various lines of work within the organization can translate into several financial and nonfinancial benefits, such as revenue generation through on-time market launches, avoided or reduced opportunity costs, reduced operational costs, higher customer goodwill and revenue retention, transparency, and even better employee engagement.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><b><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Simple or complex?</span></b><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">There are many factors that make programs simple or complex to execute, such as:</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Number of projects</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Dependencies</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Size of project teams</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Resource availability/capacity</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Prioritization of the initiative</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Degree to which roles and responsibilities of project teams are well defined</span><span style=" font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style=" font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Communication flows between project teams that require less coordination</span><span style=" font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style=" font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Processes followed by project teams</span><span style=" font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style=" font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Degree of transparency between the teams</span><span style=" font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l1 level1 lfo1; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style=" font-family: Symbol; font-size: 10.0pt; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;">·<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Silos within the organization</span><span style=" font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">The world of strategic program management is usually complex. Simple programs are hard to find, unless you are a small organization with a tightly knit set of teams and only one or two objectives to work on. The reality is that things start becoming complex even in small or midsized organizations when there are multiple issues at play.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><b><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">How does complexity impact programs?</span></b><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">As organizations grow in size, they usually spread their operations, increase the number of their product offerings, try to become more cost efficient, and create specialized units for different functional areas (marketing, finance, sales, legal, engineering, technical operations, customer support and service, business intelligence, etc.). This suggests that organizations should pay attention to their most important goals while structuring their programs. That can be difficult, as different functional groups of the organization may be working on multiple priorities that might be competing with each other.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style=" background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><b><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">How do Agile principles help in dealing with complexity?</span></b><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /><a href="http://agilemanifesto.org/principles.html"><span style="color: #ff6319; font-family: "Helvetica","sans-serif"; font-size: 10.0pt; text-decoration: none; text-underline: none;">Principles</span></a></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> laid down along with the Agile Manifesto can be useful in addressing issues related to complexity of programs. Even though these principles are heavily colored with nuances of software development, they can be applied in addressing issues related to complex program management:</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><br /></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">1.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Organizations usually have a strategy that is supposed to convey to its employees what is most important for its success in the coming period. This strategy usually includes what the leadership sees as most valuable to its customers. Organizations that manage successful programs are able to prioritize those programs as per their strategy and focus their energy into those initiatives that are most important to their customers.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">2.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">We welcome changing requirements, even late in development.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Agile processes harness change for the customer's competitive advantage: Just as with software development teams using the Agile process, it is desirable that the rest of the teams are attuned to changing market conditions or new insights (whether external or internal to the organization) that might require the product or a service to take a different direction than initially conceived. If all teams are receptive to change, there is a greater chance that the needs of customers will remain the central focus.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">3.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">We deliver working software frequently, from every couple of weeks to every couple of months, with a preference for the shorter timescale.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Just as Agile software development teams manage their work, such as working on small chunks, it makes sense for program teams to show off their work in short cycles so that the rest of the organization knows how the entire effort is progressing. Examples include iterations on sales and marketing strategy by the sales and marketing teams, iterations on customer communication/rollout planning by relevant teams, iterations on a new product or major functionality by the development teams.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">4.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Businesspeople and developers must work together daily throughout the project.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> There is great value in understanding the business perspective while building software. The same is true for other functional groups within the organization, who may not be as involved in building the software as they are in maintaining it. If the development itself is complicated and there are multiple development teams involved, it becomes even more important to keep everyone aligned with business expectations so that the program progresses in the right direction.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">5.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">We build projects around motivated individuals.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Give them the environment and support they need, and trust them to get the job done: All teams involved in a strategic initiative need to be motivated to deliver as per customer needs. If the environment encourages favoritism instead of making decisions based on merit, there are chances that everyone will not give their best to fulfill the goal of the program, likely impacting it adversely.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">6.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Face-to-face communication impacts teams' effectiveness by helping them build rapport and find solutions to bottlenecks and problems quickly. This is true for programs, even though it is much simpler to institutionalize daily face-to-face communication for a co-located team of five to seven people who are working on a single objective. While this is true, program teams should synchronize as often as they can and use technology to fill the gaps if they are not co-located.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">7.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Working software is the primary measure of progress.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> This principle is most useful in complicated projects involving multiple software development teams. Even when other nondevelopment teams are involved in a program, software development is often on the critical path, and that is often where most of the costs are incurred. So it makes sense to measure and track the progress made on working software. Likewise, program teams should measure and track progress of other non-software development deliverables that are required for readiness to deliver the product or service to the end users (launch readiness).</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">8.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Agile processes promote sustainable development.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> The sponsors, developers, and users should be able to maintain a constant pace indefinitely. From the program management perspective, all teams should maintain and deliver at a pace based on the work needed to satisfy the program objective. In many situations, one team might start its work after another team has delivered. For example, the team in charge of invoicing may only be able to update the boilerplate of a product after that product is ready and the legal team has delivered the boilerplate to them. Dependencies such as this need to be tackled by program managers, along with the teams, when planning cross-team programs. When program management is sustainable, dependencies surface regularly and are addressed routinely -- kind of like the way it works within a small Scrum team, where those dependencies surface and are resolved on a daily basis.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">9.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Continuous attention to technical excellence and good design enhances agility.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> There is a balance between doing the right things and doing things right. When in a rush, teams may be tempted to cut corners in order to deliver on time. Sometimes this tendency might be driven by a business need that cannot be overruled, and teams are forced to take shortcuts. When this happens, teams must identify and track this as debt that they need to repay at a later stage (sooner is better, as with any debt that incurs an interest cost). Repaying debt regularly and doing things right ensures that the team does not slow down (or become bankrupt!).</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">10.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Simplicity -- the art of maximizing the amount of work not done -- is essential.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Even in case of complex programs, organizations should strive for simplicity. Transparency and visibility are needed in order to create simplicity and maintain the flow of work between teams.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">11.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">The best architectures, requirements, and designs emerge from self-organizing teams.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Agile encourages self-organization, which can be useful when managing programs. For multiple teams, this starts to happen when the each team is considered a unit and the overarching program team is considered the team that needs to reorganize. This is a question of mind-set and is in some ways easier to understand in case of small teams. When multiple teams are involved and each of them has slightly different (at times divergent) goals, self-organization can be difficult to achieve. That is where transparency, prioritization, and visibility of organizational objectives to all teams are useful.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="line-height: 15.0pt; margin-left: 18.75pt; mso-list: l0 level1 lfo2; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; tab-stops: list .5in; text-indent: -.25in;"><!--[if !supportLists]--><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: Helvetica;">12.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;"> </span></span><!--[endif]--><i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.</span></i><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"> Inspecting and adapting at regular intervals is necessary to re-enforce good practices and make improvements. Agile encourages teams to practice self-sustained introspection and retrospectives. This is an important tool for program teams to review and use to fine-tune their practices for long-term success.</span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";"><br /><b>Summary</b></span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><div style="margin-bottom: 0.0001pt;"><span style=" background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><br /></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">Agile </span><span style="background-position: initial initial; background-repeat: initial initial; font-family: 'Times New Roman', serif; font-size: 13.5pt;"><a href="http://agilemanifesto.org/principles.html"><span style="color: #ff6319; font-family: "Helvetica","sans-serif"; font-size: 10.0pt; text-decoration: none; text-underline: none;">principles</span></a></span><span style="font-family: "Helvetica","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman";">, though exhibiting an overlay of software development influences, can be valuable for managing programs involving multiple teams from diverse functional groups.</span><span style="font-family: 'Times New Roman', serif; font-size: 13.5pt;"><o:p></o:p></span></div><br /><div><br /></div></div></div><h2 style="text-align: left;"></h2></div>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-29011808716575574862012-02-19T21:10:00.000-08:002021-03-20T12:46:36.847-07:00Goldtaking Notes - Sustainable Pace, Agile India 2012<div dir="ltr" style="text-align: left;">Here are the audience notes from the GoldTaking Exercise done at Agile India 2012 during the session on "<a href="http://dl.dropbox.com/u/60636068/AgileIndia2012Presentation.pdf" target="_blank">Slowing down to speed up: Encouraging sustainable pace in teams</a>" on 19-Feb-2012.<br /><br />Final slides are <a href="http://dl.dropbox.com/u/60636068/AgileIndia2012Presentation.pdf" target="_blank">here</a>. <br /><br />Video from the session:<br /><div style="clear: both; text-align: left;"><object class="" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" data-thumbnail-src="http://3.gvt0.com/vi/LgvnhuyCYuc/0.jpg" height="266" width="320"><param name="movie" value="http://www.youtube.com/v/LgvnhuyCYuc&fs=1&source=uds" /><param name="bgcolor" value="#FFFFFF" /><embed height="266" src="http://www.youtube.com/v/LgvnhuyCYuc&fs=1&source=uds" type="application/x-shockwave-flash" width="320"></embed></object></div><br /><br /><u><b>Group 1: How to motivate team to deliver at sustainable pace</b></u><br /><ol style="text-align: left;"><li>Acknowledge the achievements</li><li>Environment, open culture, celebrate success</li><li>When things go wrong, personal attacks should be avoided. Learn to internalize and change</li><li>Celebrate with connection to purpose of work</li><li>Try adn figure out why team is demoralized and plug the issues</li><li>Understand the mindset of individuals to understand their de-motivators or motivators. It is possible that coaching will vary from person to person</li><li>Make team members feel safe and secure to out of demotivation</li><li>It is good to make mistakes but learn from them. Difference between personal and professional.</li><li>Over-pampering should be avoided. Put up facts, and be straight-forward</li><li>Like volleyball, coach should ask for timeouts if required</li><li> Practice and preach respect between team members, gain trust</li><li>Challenge team on collective ownership</li><li>Team building</li></ol><u><b>Group 2: Tackling Management Interference at Sprint Planning</b></u><br /><ol style="text-align: left;"><li>Do not over-commit</li><li>Rely on velocity and capacity for committing work</li><li>Scrum Master should facilitate planning and protect team</li><li>There can be client interference causing pressure on management</li><li>There is need to adopt new work culture of Agile</li><li>Lack of clear acceptance criteria upfront during planning</li><li>Make sure all the stakeholders attend the sprint planning meeting</li><li>Re-prioritizing of Product backlog by PMs causes disruptions</li><li>Lack of trust: PM should not commit on behalf of the team at/outside Sprint Planning</li><li>Development overflows beyond one sprint</li><ol><li>Plan in a way that this does not happen</li><li>Estimate for less, specially when team members are shared</li></ol><li>(Only as much as possible) Accurately estimate/predict the team velocity to know the number of points to take this current sprint</li><li>Under-commit but over-achieve</li><li>What should happen if more points need to be delivered to client than what the team can deliver?</li><ol><li>If the team cannot deliver the points, then team should say "no"</li></ol></ol><u><b>Group 3: Motivation</b></u><br /><ol style="text-align: left;"><li>Leaders have to trust. Sustainable pace is a good way of building trust</li><li>Dan Pink -> Motivation</li><li>Do you buy into the company objective -> Helps motivate people</li><li>Behavior that is appreciated, gets respected</li><li>Stretch goals can help people grow fast</li><li>Individuals knowing how they are contributing to the bigger picture</li><li>Exposure to customers: Know about Customer's needs and vision</li><li>If team values opinion you feel you matter, need to be noticed</li><li>Appreciation of individuals from external sources over appreciation of teams may demotivate others on the team</li><ol><li>If the recipient appreciates the team that may help</li></ol><li>Team finds ways to appreciate/motivate high performers so perhaps no external appreciations needed!?</li><li>Transparency at all levels is a pre-requisite for motivation</li><li>Recognize team contribution</li></ol><u><b>Group 4: Ad-Hoc to sustainable pace </b></u><br /><ol style="text-align: left;"><li>Experience: Last minute checkins, Slack and work inflow reduction after release</li><li><b>Burned down before release, then next sprint gets off to slow-start</b></li><li>Why this big-effort before the release? May be things were not really done!</li><li>Expectations to go faster than you really can go, causes the problem</li><li><b>Management push</b></li><ol><li>Educate Manager? No, that addresses just one problem</li><li>You are actually not done if that happens</li><li>Provide dates to managers that shows the real pace and use that as a basis for planning </li></ol><li><b>Improve effectiveness</b></li><ol><li>Non-value added requirements, for example paperwork. Have someone else do it - hire a clerk!</li><li>Identify activities that are taking time and see if they can be reduced to save time</li><li>Use CI and increased automation to release more often</li></ol><li>Use scrum prioritization to make hard and real prioritization</li><li>Avoid "Goldplating" - over-engineering</li><li>Zero defects to make sure it is really done</li><li>Piling up work to test at the end of sprint is risky</li><li><b>Argument about ability to swarm around stories. Some have seen it happen, some have not</b><b> </b></li><li><b>Positive experience with testers collaborating with developers (pair) from start. Done=> All test cases targeted => Done</b></li><li>How much time to finish a story?<b> </b>3 days on average, some have minimum 3 days of dev. effort.</li><li><b>Tester writes test cases. Developers start developing at the same time they get the test cases</b></li></ol><div><b><br /></b></div></div>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-36166401066877861212011-12-16T22:18:00.000-08:002021-03-20T08:22:06.975-07:00Agile India 2012: Slowing down to Speed up: Encouraging sustainable
pace in teams<div dir="ltr" style="text-align: left;"><div style="clear: both; text-align: center;"></div>Agile India 2012: <a href="http://submit2012india.agilealliance.org/node/8962" target="_blank">Slowing down to Speed up: Encouraging sustainable pace in teams</a><br /><br />Find the final presentation <a href="http://dl.dropbox.com/u/60636068/AgileIndia2012Presentation.pdf" target="_blank">here</a>.<br /><br /><b>Here is the description:</b><br /><br />We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex.<br />Coaches & Practitioners, participate in this workshop and leave with thoughts that will help your teams adopt and practice sustainable pace, and delight your customers over and over again.<br /><div><div></div><div><b>Process/Mechanics</b></div><div><div>Introduction to the topic, understanding participant expectations - 10 minutes<br />Achieving sustainable pace - 20 minutes<br />Workshop briefing and topic selection - 10 minutes : Participants will propose and select topics for deeper discussions Workshop - 30 minutes : <i>Goldtaking (The “Goldtaking” format was introduced by Jan-Erik Sandberg and Lars Skaar at Agile2008 and is a variation of the open space format)</i><br />Workshop debrief and discussion - 20 minutes </div></div></div><div><div></div><div><b>Learning outcomes</b></div><div><div></div><div style="text-align: left;">In a highly competitive world, delighting customers is no longer optional. Steve Denning, in his book “The Leader’s Guide to Radical Management”), mentions that the goal of an organization is <b>“Customer Delight”</b>, as opposed to making money for its shareholders. Going by this goal in mind, we will examine how we can use Agile as a means to make our teams and organizations successful.</div><div></div><div>During this workshop, we will explore:<br /><ul style="text-align: left;"><li><b>Sustainable pace - Importance and challenges:</b> </li><li><i>How does it result in customer delight?</i></li><li><i>How agile values are challenged without sustainable pace?</i></li><li><i>What prevents us in delivering at a sustainable pace? (such as competitive surroundings, culture, organization structure, conflicting priorities, old habits, antiquated tools, technical debt)</i></li><li><b>How can we coach teams towards sustainable pace?:</b></li><li><i>Self realization</i></li><li><i>Importance of contextual information</i></li><li><i>Understanding and responding to Force fields</i></li><li><i>Challenging status quo: Stakeholder alignment and participation</i></li><li><i>Building your team into Agile craftsmen, and not Agile mechanics</i></li><li><i>Using Data as a vehicle for change</i></li><li><i>Inspecting and adapting</i></li><li><i>Continued engagement</i></li></ul></div></div></div></div>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-29949729104880246622010-11-30T08:46:00.000-08:002021-03-20T08:22:05.303-07:00Agile or Waterfall? That is the question<div dir="ltr" style="text-align: left;"><a href=""><img alt="" border="0" id="BLOGGER_PHOTO_ID_5545417007114046370" src="" style="cursor: hand; cursor: pointer; float: right; height: 100px; margin: 0 0 10px 10px; width: 200px;" /></a><br /><a href=""><img alt="" border="0" id="BLOGGER_PHOTO_ID_5545417002607349938" src="" style="cursor: hand; cursor: pointer; float: right; height: 112px; margin: 0 0 10px 10px; width: 200px;" /></a><br /><a href=""><img alt="" border="0" id="BLOGGER_PHOTO_ID_5545416994305792098" src="" style="cursor: hand; cursor: pointer; float: right; height: 192px; margin: 0 0 10px 10px; width: 200px;" /></a><br /><a href=""><img alt="" border="0" id="BLOGGER_PHOTO_ID_5545416992229822754" src="" style="cursor: hand; cursor: pointer; float: right; height: 100px; margin: 0 0 10px 10px; width: 200px;" /></a><br /><a href=""><img alt="" border="0" id="BLOGGER_PHOTO_ID_5545416989160473186" src="" style="cursor: hand; cursor: pointer; float: right; height: 100px; margin: 0 0 10px 10px; width: 200px;" /></a><br />Are you and your team ready for the changes that agile brings?<br /><br />Visit the <a href="http://www.aplnhouston.org/index.php/chapter-meetings/past-meetings/176-apln-houston-chapter-meeting-nov-18-2010-600-pm">APLN Houston Website</a> for the presentation and a "sample Agile Decision matrix" on this topic. Teams new to Agile and Scrum might find this useful. Note that this is just a starting point - it is beneficial to customize the matrix.<br /><br />Gave this presentation with Prashant Patel on Nov 18th, 2010.<br />Thanks to the APLN Houston leadership for organizing the event.</div>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-47904593652138020652010-10-19T08:21:00.000-07:002021-03-20T08:22:05.359-07:00Breaking Scrum: Scope changes within the sprint...A discussion I started on Linked:<br/><br/><b>Breaking Scrum: Scope changes within the sprint...</b><br/>Hi,<br/>Looking a "list of reasons" on why product-owner-pushed scope change during the sprint breaks scrum...<br/><br/>Few I can think of (please add):<br/>- Takes away the focus from the current functionality<br/>- Reduces team ownership<br/>- Impacts Quality<br/>- Impacts Velocity<br/>- .......<br/><br/>Thanks!<br/>Rahul<br/><br/>3 months ago<br/><br/><b>Prasanna Raghavendra </b>• The basic essense of agile to me is getting joy in the journey (see here: http://2srp.blogspot.com/2010/06/joy-of-journey.html). One should be successful in the small steps to make sure there is continuous passion and teaming, If this fails, everything breaks!<br/><br/><b>Mike Caddell </b>• A scope change during a sprint - which is a contradiction in terms - invalidates the fundamental agreement and commitment that bounds a Scrum iteration. The team commits to complete a set of functionality as prioritized by the Product Owner and agreed to by the team. The Product Owner in turn commits to helping define and elaborate the agreed on scope in a timely manner to enable the team to do it's work; and only the agreed on scope, nothing else unless the team finishes early and then picks the next highest priority Release Backlog item.<br/><br/>If the team is asked/required to accomplish a different scope of work during the sprint, the mutual commitment to the previously agreed to scope is thus invalidated. At this point, the sprint should be terminated and a new sprint with the new scope begun - starting with Backlog Grooming and Sprint Planning.<br/><br/><b>Julie Hendry </b>• I agree Mike, although it often depends on what is meant by 'scope change' - is is the overall deliverable or is it simply that we discover more detail?<br/><br/>I've seen successful teams accept some changes within scrum as long as the changes are agree and communicated, and do not change the underlying goal of that sprint.<br/><br/><b>Rahul Sawhney </b>• Thanks all for comments.<br/>@Julie, To clarify I mean "goal changing" and "deliverable changing" sort of changes. I do not mean discovery of some more details.<br/><br/><b>Mike Caddell </b>• @Julie - a great clarification!<br/><br/>I meant as Rahul indicates, a change in the objective or the actual content.<br/><br/>As this discussion clearly illustrates conversation almost always illuminates more detail - which is why we value Individuals and Interactions more than Process and Tools!<br/><br/><b>Derek Neighbors </b>• Is the reason why they do? or the reason why they shouldn't be allowed to?<br/><br/>The reason they do... the team allows them. The don't enforce some penalty in breaking the contract.<br/><br/>The reason they shouldn't be allowed to. A key premise of agile resolves around trust. Changing course mid sprint breaks trust and deteriorates the relationship.<br/><br/><b>Prasanna Raghavendra </b>• I am seeing this discussion going similar to building a stringent chinese wall between the product owners and the team and closing doors on genuine yet possible changes within iterations. Like I mentioned earlier (brewity killed clarity in my earlier note, I guess!), the focus should be on small but quick win at the end every iteration for the entire team (including product owners). That would mean there should be constant communication and acceptability of what can be done for the changes coming-in while appreciating concerns from both end. A "genuine" change coming in within an iteration should be discussed and accepted when possible while showcasing what it means for the dev teams to pick it up. This is when teaming and binding becomes stronger. Product owners should also have strong reasons why the change envisaged cannot wait until the next iteration.<br/><br/>I would discourage a generic and rigid process coming in the way of teaming. Agile is not a process but it is a set of natural tendancies teams follow to bond, and that should take precendence. it is interesting to note that we are losing our this natural behaviour and find it hard to let those take precendence.<br/><br/><b>Rahul Sawhney </b>• @Prassana - I agree with you completely.<br/><br/>Just to bring the discussion back towards my question, refining it a bit....<br/>What are the after-effects (short term and long term) of having the "sprint-goal changing" scope changes, which would take the focus away from the team to deliver what they committed?<br/><br/>So far, we have seen some points indicated above, would like to learn more perspectives, experiences when this happened etc..<br/><br/><b>Jeff Smathers, CSM </b>• Rahul, If I understand your question, I think that Derek and Mike have great answers. I will try to summarize for my own benefit. If the scope change is so large it changes the sprint goal then the team cannot meet its commitments and the sprint is no longer valid and should be ended. A new sprint needs to be planned and started to address the changes. Depending on the maturity of the team, the trust between members and the quality of their relationships could suffer. Keeping to the commitments defined by the sprint goal is very important.<br/><br/><b>Jason Little </b>• I wouldn't worry so much about the after-effects as I would in trying to figure out why the scope keeps changing every sprint.<br/><br/>Some context would be helpful. Is this team supporting an existing product? Are the interruptions due to customer complaints or support issues? If so, Scrum doesn't work well in that situation.<br/><br/>Is the PO having problems grooming the backlog to get stuff ready for the sprint? Is there a lack of overall product direction? Are different stakeholders pushing conflicting priorities?<br/><br/>A sprint being constantly interrupted is often the symptom of a deeper problem. Focusing on Scrum as dogma isn't going to solve the problem and you'll end up creating more dysfunction and trust issues between the team and the PO.<br/><br/><b>John Clifford </b>• In Scrum, the team's commitment to accomplish the items on the sprint backlog that starts the sprint is matched by the Product Owner's commitment to observe and respect that commitment by not trying to change the agreed-upon scope for the duration of the sprint. One can't work without the other. I would argue that a Product Owner who continually wants to change scope during the sprint isn't following the Scrum process and doesn't respect the team or their commitment. In my experience, this happens because the Product Owner fails to take ownership of the product backlog; either he procrastinates on prioritization until the last moment and then overlooks stakeholder commitments that drive prioritization needs, and/or fails to take responsibility for ensuring backlog items are groomed and prepared prior to sprint planning.<br/><br/>Not having objective, quantitative, and binary acceptance criteria for sprint backlog items is one of the problems leading to scope change; if the team has no defined criteria for the complete story then what is to stop the Product Owner from whipsawing them around? Therefore, the Product Owner should ensure that sufficiently-defined acceptance criteria exists for all stories that she will bring to the sprint planning meeting... and the team should refuse to consider any item lacking this. This isn't to say that the team and the Product Owner should be at each others' throats, but instead to say the team may need to spend some time during the sprint planning meeting working with the Product Owner to create sufficiently-defined acceptance criteria.<br/><br/>(Product backlog items with valid acceptance criteria and that have been estimated are often referred to as 'Ready-Ready', in the way that sprint backlog items that are completed according to the Definition of Done and all acceptance criteria are referred to as 'Done-Done-Done-Done.' Effective Product Owners always have at least one sprint's worth of backlog items in a 'Ready-Ready' state before the start of a sprint planning meeting.)<br/><br/>I'm a huge believer in not hiding dysfunction, because you can't fix it if you refuse to see it. In the above situation, the sprint planning meeting timebox will most likely end with only one or two items that have valid acceptance criteria; so be it. The Product Owner will need to accept that bandwidth may need to be reserved during the sprint to work on additional items' acceptance criteria in order to be ready for the next sprint; if the team finishes with the committed items early, they can either drag additional items into the sprint or end the sprint early and re-plan/re-launch. At any rate, this should be discussed at the sprint retrospective and a solution devised that will prevent this from happening again should be implemented.<br/><br/>As others have mentioned, if the team believes that an item's scope has changed to the extent that the original commitment is invalidated, then they have the authority to reject the changes and not complete the item... and this should be discussed at the retrospective. Or, if the Product Owner really wants to change scope, e.g., substitute a new sprint backlog item for an existing one, even if the item estimates are identical, then the team has the authority to accept or reject the change, to the extent of cancelling the sprint and re-planning. Again, to expose dysfunction, I counsel against accepting ANY sprint backlog changes, not to be a jerk or uncooperative, but in order to force the issue to the surface... Product Owners who continually fail to prioritize and want another bite at the apple, for whatever reason, are a common issue.<br/><br/><b>Andy Dent </b>• A few thoughts on this, against a background of multiple scrum teams collaborating internationally, spanning 24 hour time differences. We have architectural separation of much of the work but that translates into one team having the other two as customers.<br/><br/>We could take the bloody-minded approach of just saying "no" but that risks some bugs being blockers to another team for an entire sprint.<br/><br/>An alternative is for the team to identify one or two people as responders to handle urgent cross-team requests. They can have a task allocated in the sprint which is basically a budget of their time, to be whittled down over the course of the sprint and leaving them free to do other tasks of moderate size.<br/><br/>When it comes to tasks being inserted into the sprint, another pet idea of mine is to mandate that tasks with twice the number of story points have to be removed.<br/><br/>This reflects the loss of velocity from something unplanned being included and emphasises the seriousness of the interruption to the product owner. I'd love to know if anyone applies this, how they get on!<br/><br/><b>Raul Xavier Neto </b>• I´ve got a little intrigued with that many arguments being so dogmatic about scrum. I think that one of the best points of agile (in this case, scrum) is to help teams cope with change. Change that is a big reality on every software project.<br/><br/>I´ll go with Jason and Prasanna telling you that the best thing for your team is to find out why the owner is changing that much and try to bring him to the team, where those changes should be agreed by the team with good discussion.<br/><br/>Speaking of dogmas, maybe the initial phase is too dark in the owner´s head, maybe the team is not sure about the concept or something else. To ease that kind of thing, that usually comes in the beginning of the project, you can try to reduce the sprint duration, bring the owner closer to the team, try different approaches to put the team as one peace. Scrum is not a Religion, it only guides teams to achieve good results, but the principles are the important thing, not the "rules". If you have to, adjust the "rules" to your needs.<br/><br/><b>Prasanna Raghavendra </b>• @ Raul, @Jason: Bingo!<br/><br/>@Rahul: It is less about worrying about after effects than accepting it as another pragmatic anamoly and see why it occurs and how it can be fixed.<br/><br/><b>Rahul Sawhney </b>• Thanks John - I enjoyed reading what you have written here.<br/>Thanks to everyone else too - great insight!<br/><br/><b>Cuan Mulligan </b>• @Rahul, the impact for me is one of cost.<br/><br/>for example, lets say the PO has aprpoval to spend $x on the delivery of a project. It is the role of the PO to ensure the best spend of the companies money.<br/><br/>If the PO keeps changing their mind, this will consume time (cost) and reduce the teams ability to deliver the project benifit for the agreed amount of money.<br/><br/>If the changes are small , ie refeinments, then this should not be an issue. However I have worked with PO, who make quite dramatic changes during a sprint, and then wonder why the project did not deliver. The upside was that they learnt a valuable lesson, and stopped this behaviour.<br/><br/><b>Gail E. Harris </b>• The fundamental question in this discussion thread is about product-owner driven scope changes during a sprint breaking Scrum. Well, as someone else wrote, Agile approaches like Scrum are all about being agile, and, as it turns out, changing the scope during the sprint doesn't break Scrum at all.<br/><br/>In Ken Schwaber's book "Agile Project Management with Scrum" he describes exactly how to handle this. He says that "management could abnormally terminate the Sprint" at which point there would be a new Sprint planning meeting. Ken further notes that this new planning meeting would make the action highly visible and thus hopefully product owners would not make a habit of it.<br/><br/>It's also worthwhile to note that a new opportunity to change the scope is never more than four weeks away. Once they realize this many product owner's find that four weeks from now is more than soon enough.<br/><br/><b>Griffin Jones </b>• We have a very small team, working in a start-up.<br/>Priorities change.<br/><br/>When targets-of-opportunity appear, ownership will pause the sprint as we deal with the new higher priority. The owner makes the informed choice.<br/><br/>Long pauses force a clean re-plan of the sprint. Too much switching reduces velocity. But the owner values responsiveness from development, and is willing to accept reduced velocity in exchange.<br/><br/><b>Rahul Sawhney </b>• @Cuan,Gail and Griffin, Thanks I was looking for exactly these inputs!<br/><br/>I do believe that this does not break Scrum as a framework. When Scrum is done incorrectly, (i.e. when PO makes significant changes without agreeing with the team and does not allow terminating or pausing the sprint, and does so regularly), the team gets demotivated and starts falling apart. And as Cuan mentioned, not learning from experience escalates costs and reduces team's ability to deliver and impacts collaboration.Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com1tag:blogger.com,1999:blog-5094680508146116163.post-35244593150272799492010-10-04T09:18:00.000-07:002021-03-20T08:22:05.465-07:00Have an Initial Conversation to Start an Agile Project<div dir="ltr" style="text-align: left;"><div dir="ltr" style="text-align: left;">This article was published on <a href="http://scrumalliance.org/articles/188-have-an-initial-conversation-to-start-an-agile-project">Scrum Alliance</a> in Oct 2010<br /><br />In this article, Prashant Patel and I present:<br />• The different aspects of this conversation - the parameters that we consider.<br />• Why these parameters are relevant in the context of Baker Hughes Inc.<br />• The impact of these parameters on solution delivery<br /><br /><h3 style="text-align: left;">Have an Initial Conversation to Start an Agile Project</h3>The Baker Hughes Product Development Lifecycle starts with discovery and inception phases. The delivery teams start engaging with the customers during the inception stage. By the end of inception, business requirements are understood at a high level and stakeholders from different teams who will be involved in the project are identified. This is when discussions are held for selecting the appropriate solution delivery methodology.<br /><br />The choice of methodology impacts how the different stakeholders engage with the project. We have seen that in order to improve the chances of success for any project, the solution delivery methodology and the level of commitment needed should be understood upfront by all stakeholders. To that end, it is important that there is representation from multiple stakeholders, including but not limited to business, development, testing, agile coach, project management and resource management.<br /><br />The stakeholders should be aware of the agile methodology and scrum framework for having this conversation. It is beneficial if they understand the rigor agile brings with respect to solution delivery and how it is different from waterfall.</div><h4 style="text-align: left;">Parameters</h4>As part of our methodology selection criteria, the team examines the following basic parameters. During this conversation, the parameters and their implications are discussed in detail and a rating is given to each sub-parameter. All parameters need to be rated to consolidate the results, but it is not necessary that all parameters need to be rated favorably as a criteria for going agile; however, parameters with lower scores are considered risks associated with project execution. It is more important for stakeholders to have the conversation, understand their constraints and make a conscious selection of the solution delivery methodology, than the actual number results from this assessment. At the end of inception, the team needs to agree on the solution methodology based on its own judgment.<br /><br />These parameters are customized to work in our environment and can be discussed in any order of preference. Organizations are encouraged to devise their own criteria based on the guiding principles of agile and assign their own weights to individual parameters.<br /><h4 style="border: 0px; font-family: Georgia, serif; font-size: 15px; font-style: inherit; font-weight: normal; letter-spacing: 1px; margin: 1.25em 0px 0.75em; padding: 0px; vertical-align: baseline;"></h4><h4 style="text-align: left;">Collaboration with Business</h4>Collaboration with customers is critical to successfully execute an agile project. That is why it has been explicitly called out in the Agile Manifesto (www.agile manifesto.org) – “Customer collaboration over contract negotiation”. As part of collaboration with business we examine the following: <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><strong>Availability of Business/Customer for clarifications</strong><br />Some customers prefer to go away after the initial discussions on project scope and requirements and be available only when the complete scope has been developed to check and provide feedback. This approach does not work very well with agile and Scrum teams. Short feedback cycles of two to four weeks require that customers are engaged throughout the project lifecycle and are available to provide feedback at the end of each sprint. During the sprint planning, teams may identify certain open points, questions and reminders for discussion during the sprint execution. These may also need clarifications from the customer even while the sprint is in progress. In order to meet the sprint commitment, the stakeholders need to ensure that passing on these clarifications to the team does not require too much time.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><strong>Flexibility towards scope reprioritization </strong><br />Agile teams thrive when they can deliver what the customer needs. Their focus is to continue to deliver maximum business value in shortest possible time. This is only possible if the scope is revisited frequently and not cast in stone at the beginning of the project. As part of revisiting the scope, it is essential that the priorities for the remaining work are revisited as well.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><strong>Identification of acceptance criteria</strong><br />The stakeholders discuss and agree that the team needs to be given fair visibility and understanding of the scope items at the beginning of every sprint so that they can make reasonable commitments on what can be delivered. For this reason, we encourage the stakeholders to identify the acceptance criteria for each scope item at the time of sprint planning.</li></ul><h4 style="text-align: left;">Project Constraints</h4>Projects may have multiple constraints that may need to be satisfied. Each organization, group or team may have their own set of constraints that may be evaluated during the conversation – These should be heavily customized depending on the project situation. Below are the criteria that we use at Baker Hughes:<br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Outgoing and incoming dependencies</b><br />Dependencies with external teams add to system complexity. Ensuring that the project progresses as required, requires coordinating multiple dependencies. At times, dependencies may impose constraints such as: force special schedule requirements for certain scope items, make a part of scope definition more rigid, and make certain resources available to the team only in a particular time window. A large number of dependencies require allocating a significant amount of effort towards synchronizing the work of different teams. In that case, stakeholders need to discuss how these dependencies would be managed in the context of agile.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Documentation needs</b>The agile manifesto calls for “Working software over comprehensive documentation”. Stakeholders need to discuss and agree about the level of documentation that will be created. For agile projects, stakeholders should agree to create only that documentation which will have value and will be easily maintained. Regulatory aspects, which may be relevant to some projects, should be considered too.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Resource allocation and availability</b>For agile projects, we encourage the team members to be allocated 100% to the project instead of allocating percentages. We also encourage them to retain resources for multiple versions of the product and we discourage teams from changing resources while a sprint is in progress. This helps sustain delivering to sprint level commitments and makes resources own the sprint results and a predictable team velocity.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Collocation</b>Collocation of team members improves intra-team communication and improves velocity. Multi-located teams can do agile with the aid of communication and collaboration tools.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Build automation</b>Teams are encouraged to put build automation in place as early as possible during development sprints. If teams do not automate their builds, a lot of time is spent in manual builds and continuous integration cannot be accomplished.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Unit and System Test automation</b>Developing in short cycles and sustaining good quality and high velocity requires that team should be able to test what it develops quickly and effectively. This becomes difficult with manual tests as system becomes more and more complex with each passing sprint and regular addition of new functionality. Creating a good set of automated tests helps in ensuring that system health is maintained even after multiple sprints without sacrificing speed of delivery.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Empowerment</b>An empowered team performs faster and better, and is more accountable for its results as compared to teams that have not been empowered to make certain decisions regarding their work.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Product Owner empowerment</b>During the conversation, a product owner is clearly identified and expectations from the role are discussed. For agile projects, it is important that the stakeholders empower the product owner to make quick decisions on the project scope and provide direction to the team about what needs to be done in the project. The product owner is also empowered to decide on the priorities of the items in the product backlog.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Scrum Master empowerment</b>A Scrum Master is also identified clearly to help the team in removing impediments. The stakeholders and the product owner should empower the Scrum Master to act in the interest of the team, represent the team and say “No” to disturbances.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Team empowerment</b>The stakeholders empower the team to go into agile and Scrum with an understanding that they are empowered to provide fresh commitment at the beginning of each sprint. Since the details for many items in the scope may be discovered while the project is in project, initial estimates of the team are only based on the visibility of the team into the requirements at the beginning of the project. Stakeholders discuss and agree that these estimates may be revised later on in the project as the team gains more visibility on what needs to be done.</li></ul><h3 style="text-align: left;">More of the same</h3>To be able to deliver new functionality in short cycles, it helps if the team members are well aware of the business domain and technology. <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Team’s acquaintance with business domain</b>The stakeholders discuss about the team’s awareness of the business domain and if it has executed similar projects in the past. If business domain is not well understood by the team, the gaps are identified and team is coached during the project.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Team acquaintance with Technology</b>The stakeholders also discuss the need for the team members’ acquaintance with the technology. At times the technology itself may be new or the team members may not be acquainted with advanced concepts that might be used in the project. In such cases, or where there are gaps, the team should be coached. This might involve planning for additional technical trainings for the team and/or on the job coaching by experienced technical staff.</li></ul><h3 style="text-align: left;">Team characteristics</h3>Fast- paced agile development requires giving importance to “Individual and Interactions over processes and tools“. It becomes crucial to assess if the team is well suited to perform in an agile setting. <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Team size</b>The stakeholders discuss about number of developers and testers that will be on the team. If there are too many people in the team, it impacts the team’s focus and activities (such as daily scrum meeting, making a sprint goal commitment) start taking longer time. This is attributed to the number of possible communication channels within the team, which increases substantially with team size. Based on our projects at Baker Hughes Inc., we have laid down the appropriate range from five to ten, with five to seven being the ideal range.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Agile coaching and awareness</b>Since the organization is new to agile, it is recommended to have an agile coach associated with the team to guide the team members with agile and Scrum. In the context of Baker Hughes Inc., the delivery organization’s Program Management Office helps the teams with agile coaching.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Number of sub-teams</b>The stakeholders discuss the internal structure of the team. If the project is too big, sub-teams may be created to keep the size of each team below ten. As of now, none of the agile projects have had to have multiple sub-teams.</li></ul><h3 style="text-align: left;">Project type and execution</h3>These parameters, in addition to the ones specified earlier, help apply agile to situations where it will yield advantageous results for the organization compared to other methodologies. During the conversation stakeholders assess the project type and try to identify the benefits expected by using Scrum and agile in the project. <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Type of project and Need for change</b>In our organization, we encourage use of agile for projects for significant enhancements, entirely new development and initial prototyping of a new concept. These projects are considered more suitable as they typically have an initial scope to start with, which can be refined over a period of time. Projects that are of production support (continuously changing scope – that cannot be controlled) and minor enhancements (having very low effort estimate) are not encouraged.<br /><br />The stakeholders also discuss the need for scope change in the projects and how agile will benefit the customer in such a situation. In cases where the scope is more or less understood and not much change is expected, the project could be executed in iterations. And in other situations, the scope can evolve as the project progresses making agile more suitable for the project.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Project duration</b>Contrary to the perception of many people, agile works best when the duration of the project spans multiple months. Such duration provides the team an opportunity to inspect and adapt their ways of working. It also provides the customer an opportunity to get the most value through regular reviews of the functionality delivered.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Mission criticality</b>The stakeholders deliberate whether or not the requirements of the project have any tolerance for defects. In the ideal world, the team should deliver defect-free product at the end of each sprint. However, in the practical world of agile, the product evolves over time and there is always scope for perfecting the product over time. There are some exceptions though where there is no room for errors, in the delivered product – examples include life-critical healthcare applications, really expensive applications (like ones used in space programs) and so on. Having executed agile projects in such situations ourselves, we do not say that agile cannot or should not be applied in such situations. We say that in such situations, it is important to realize that quality needs to be given a prime importance and extra measures need to be put in place to validate the product before its Deployment.</li></ul><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;"><b>Resource availability for Sprint zero</b>In our organization, we execute a sprint zero (we call it the formation sprint) for each agile project to build an initial product backlog and do the groundwork for executing the project such as plan number of iterations, set up the initial infrastructure and prepare a statement of work. To execute the sprint zero properly, it is necessary that the resources needed are made available. This means allocating key team members to the project and making the necessary hardware, software and tools available to them.</li></ul><h3 style="text-align: left;">Conclusion</h3>Agile and Scrum can be applied to vast variety of projects and situations. To execute projects well using agile, the need for collaboration and understanding between the customer/business and the delivery organization cannot be underscored. Basic preparations are needed in this regard and this conversation goes a long way in ensuring that happens. </div>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-360951362003460872010-06-29T08:14:00.000-07:002021-03-20T08:22:05.522-07:00Mixing Product Owner and Scrum Master rolesThe Scrum Guide says that the Product Owner and Scrum Master roles should not be played by the same person. Given below are some reasons why this is not recommended in Scrum and the possible consequences of not following this recommendation.<br /><br />- Conflict of interest - The two roles may have conflict of interest in certain situations. Product Owner is concerned about maximizing the RoI and Scrum Master protects the team from external distractions and helps remove impediments. Scrum Master works closely with the team in doing this, and the product owner provides the customer perspective to the team.<br /><br />- Bad mix - If the same person plays both the roles, the scrum master role can take a back seat. The person playing both the roles may find it very difficult to balance the needs of the customer and the commitment that the team can make. It is highly probable that s/he may burden the team with ever-so-frequent over-commitment of results and intra-sprint scope changes. This in turn can impact the team results and morale.<br /><br />- Bandwidth constraints - It may not be possible for one person to play both the roles due to lack of time. Product Owner role requires understanding the needs of the business. Depending on the project landscape this can become a very time consuming activity leaving little or now time with the person to help resolve team impediments.<br /><br /><br />Issues:<br />- What if team size is small: For Scrum the ideal team size in 5 to 9. But for any reason, even if the team is smaller than 5, it would still be better to have different people playing the two roles than letting one person play both the roles. In this situation, the role conflict becomes even more apparent.<br /><br />- What if organizational structure does not provision for a Product Owner role: Different situations warrant different solutions. For example, the Product owner could come from IT or Business. There could be a proxy Product Owner within the team who interacts closely with the Business or Customer. Since the Product owner takes the ownershiop of the priorities (and thereby the project direction), it is important that s/he has the ability and the authority to say "No" when required.Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-76666867713437558892010-02-20T08:05:00.000-08:002021-03-20T08:22:05.576-07:00How to sustain Adaptive planning<div dir="ltr" style="text-align: left;">This article was published on <a href="http://www.scrumalliance.org/articles/162-how-to-sustain-adaptive-planning">Scrum Alliance</a> in Feb 2010.<br /><h3 style="text-align: left;">How to Sustain Adaptive Planning</h3>Scrum and other agile methods recognize that responsiveness to change is an important aspect of delivering projects. They also recognize that software development is evolutionary and creative. By managing changes through Adaptive planning, Scrum provides a simple yet effective method of planning and tracking project progress. In this article, we will examine what is needed to sustain Adaptive planning and improve Team's responsiveness towards customer needs. We will examine the following factors: <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Just-enough planning</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Evolving plan, scope driven by budget and/or time</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Grooming the scope</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Trust, involvement and collaboration</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Management support</li></ul>Consider a scenario where the project is progressing as per plan, and in the middle of the project the customer approaches project manager with a request:<br /><br /><i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Customer: "I really need this functionality delivered in the project. But it is not part of the current scope. Can we make it happen as part of this project?"</i><br /><b>Possible response #1:</b> <i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Project Manager: "Unless you are okay with budget overflow and/or schedule delay. Alternatively, we can revisit the project scope but it will require us to drop certain other functionality from the scope of this project. As the effort already spent on estimation and analysis of that functionality will be wasted, please be aware that it will impact productivity."</i><br /><b>Possible response #2:</b> <i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Project Manager: "Well, I am afraid the change control board (CCB) needs to decide this. The CCB meets in two weeks and once they approve that an investigation is needed, we can investigate and inform them about the impact on our plan. The CCB can then decide whether or not this functionality can be implemented."</i><br /><b>Possible response #3:</b> <i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Project Manager/Product Owner: "I do not see a problem as long as you are okay with dropping certain low priority items from current scope of the project and getting this functionality at the end of next Sprint, assuming it fits. Let's get together and discuss."</i><br /><br />Although many responses are possible depending on the context, if the project is using Adaptive planning then a response similar to response #3 is more likely. Such a response demonstrates that the Team is well prepared to respond to change. <br /><h3 style="text-align: left;">Making Adaptive planning work</h3><h4 style="text-align: left;">- Just-enough planning</h4><img alt="" src="" style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;" width="670" /> To begin with, requirements are understood at a very high level and thereafter, the rest of the planning is driven by priority. As a rule, <i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">lesser time is spent on figuring out the details of those requirements that do not have a very high priority</i>. High priority bigger requirements are split into smaller ones so that details can be explored. Only relative size estimates (at a high level) are done at this point to get an idea of how "big" the work is. Once the work is quantified, tasks and effort are estimated for the highest priority requirements. That gives an idea of how much the Team can deliver in a Sprint. This idea is tested in the first Sprint and gives the Team a better understanding of its Velocity (or the size it can deliver in one Sprint). Using the Velocity, the Team is now in a better position to give commitments for later sprints. <br /><h4 style="text-align: left;">- Evolving plan, scope driven by budget and/or time</h4><img alt="" src="" style="border: 0px; font-family: inherit; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;" width="670" /> As the project gets underway and the Team executes multiple sprints, the Team has better visibility on the customer needs. Likewise, the customer also understands the requirements better. <i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">This understanding results in evolution of the Product Backlog</i> (e.g. changes in functionality and scope, priority). As the Product Backlog evolves, the size estimates are done for newly added requirements. The Product burndown chart shows how much work is remaining based on the revised scope in the Product Backlog. The work remaining is controlled usually by removing some low priority requirements (of size equal to the added requirements) from the scope. This ensures that scope is managed continuously based on highest priority requirements. Adapting the plan in this manner helps in providing better visibility to all stakeholders by tackling many important issues, such as: <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">How do we deliver what is most important for the customers?</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">How do we address customer feedback on what has been already delivered?</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">What are the key changes that we need to make?</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Have we addressed all the key risks for the project?</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">How much work is remaining for the project? Do we need to adjust the project scope?</li></ul><h4 style="text-align: left;">- Grooming the scope</h4>At the beginning of each Sprint, the Team makes a commitment on the functionality it can deliver. In order to make a commitment, the Team may need some time to <i style="border: 0px; font-family: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">investigate certain aspects and risks in the preceding Sprint itself</i>. In other words, sometimes it makes sense to look-ahead and reserve some time for investigation on risky items in the backlog that may be part of the next Sprint. Better insight into risky items in the Product Backlog helps the Product Owner make conscious decision on the item's priority, makes the Sprint planning exercise easier and the Team more confident. Additionally, new functionality requests by Customers can be expected at any point during the project. Sometimes, especially when the functionality is complex or due to other reasons, identifying enough details for quickly giving commitments on these new items at the beginning of the Sprint can be difficult. Grooming the scope during a previous Sprint makes sense.<br /><h4 style="text-align: left;">- Trust, involvement and collaboration</h4>Working with an adaptive plan requires a lot of trust, involvement and collaboration between the Team, the Product Owner and other key stakeholders of the project. Unfortunately this is much easier said than done. Individual stakeholders have different motivating factors and it requires time to build the trust. Things may become extremely difficult and unsustainable if the trust is lost. The effect of losing trust could result in failures such as poor quality, dramatically reduced velocity, inability to meet commitments for multiple Sprints, arguments over small stuff, high team attrition and loss of face in front of the customers. Building trust requires a lot of commitment and collaboration. The Product Owner and management should give the Team freedom to decide how much it can deliver in a Sprint. The Product Owner needs to set the right expectations between the customers and the Team. Setting unreasonable expectations can misfire in the long term. The Team may succumb to pressure of delivering more functionality and may succeed in doing so by cutting quality, or by introducing too much technical debt that becomes difficult to handle later. The ScrumMaster needs to support the Team by guarding the scope and the practices of Scrum. The Team needs to understand the needsof the Product Owner and help in achieving that goal. The Team can help in several ways, such as improving its engineering practices, making the most out of feedback, ensuring that it acts on its retrospective actions and highlights issues that are beyond control. The mechanism of "inspect and adapt" should not be interpreted as a "self-repairing system." The system will not fix the problems unless everyone involved in the process devotes the time needed and is committed to the process. The Team members (ScrumMaster, developers, testers etc.) need to work with each other to achieve the Team's sprint goal and continuously improve their ways of working. They need to work with the Product Owner to groom the scope and understand what is needed. Likewise, the Product Owner needs to collaborate with the Team throughout. If the Product Owner becomes complacent in engaging with the Team after a few Sprints then the visibility of the Team can reduce drastically, benefits achieved can be quickly erased and situation can deteriorate. The Product Owner needs to ensure that the business users and customers are appropriately engaged in the process. Without an appropriate level of engagement, there is a risk of misunderstanding the business and customer needs. <br /><h4 style="text-align: left;">- Management support</h4>In order to sustain Adaptive planning with Scrum, it becomes important that the culture of the organization understands and respects change. Organizations, where teams go agile but the management thinking does not, run a risk of quickly losing all the benefits from Agile and becoming worse than they were before. Some of the things that managements need to do include <br /><ul style="border: 0px; color: #636466; font-family: Helvetica, Arial, sans-serif; font-size: 10pt; font-style: inherit; list-style-image: initial; list-style-position: initial; margin: 1em 0px 1em 1em; padding: 0px 0px 0px 1em; vertical-align: baseline;"><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Provide long term vision, direction and priorities</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Trust and motivate their Teams</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Focus on addition of business value</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Encourage Teams to deliver quality, act on technical debt, enhance engineering practices</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Ensure continuous flow of work</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Minimize non-work related disruptions</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Facilitate removal of impediments outside the control of Teams</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Support the process of learning, inspecting and adapting</li><li style="border: 0px; font-style: inherit; margin: 0px; padding: 0px; vertical-align: baseline;">Communicate</li></ul><h3 style="text-align: left;">Conclusion</h3>Adaptive planning helps Teams handle changes to scope in a continuous manner but may become unsustainable when practiced in isolation. Other practices of Scrum, along with critical management support and understanding are critical for sustain Scrum in an organization. </div>Rahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0tag:blogger.com,1999:blog-5094680508146116163.post-51612223398249213772009-11-09T11:01:00.000-08:002021-03-20T08:22:05.634-07:00What can leaders do to enable Agile teams?Top of the mind thoughts:<br />1. Provide long term vision on where the IT department will fit in the overall value chain of the organization and how agility can help it in achieving that goal <br />2. If the long term intent is to go agile for majority of projects, create a transition backlog <br />3. Prioritize and reprioritize often <br />4. Inspect & adapt as you go along the journey <br />5. Lead by example, follow agile principles <br />6. Encourage & reward successes and support learning from failuresRahulhttp://www.blogger.com/profile/00062159200452009348noreply@blogger.com0