Agile India 2013 – Certified ScrumMaster Course by Craig Larman

Craig Larman will be presenting his well-known Certified ScrumMaster course at Agile India 2013. Craig has written several books and is also one of the leading authors on how to scale Agile.

This week we interviewed Craig and asked him several questions related to the ScrumMaster role in Scrum.

Why is a typical project manager not a scrummaster?

First, a scrummaster is a master of scrum; this has almost no overlap with the skills and responsibilities of a project manager. A key job of a scrummaster is to educate leadership, the Product Owner, and Team on the organizational design implications of adopting scrum, and how to obtain benefit from “business agility” by changes of behavior in the business group. Second, in scrum, the responsibility for the release shifts away from IT managers to the business-side “owner of the product”, who becomes the Product Owner. This business-side Product Owner “steers” directly and interacts with the Team directly, with no control by an IT project manager. Third, the concept of a “project” is eliminated, and we move to a product-oriented culture with a long-term and stable product group; consider the scrum terms: *Product* Backlog and *Product* Owner. When a Team can deliver potentially shippable product increment each Sprint, the concept of a “project” is largely dissolved. So the role is project manager is no longer necessary; almost all project management responsibilities shift to the self-managing Team, or to the business-side Product Owner. And, the scrummaster has no power over the Team; indeed, in classic scrum the team could “fire” the scrummaster from serving them if the scrummaster was not acceptable.

What advice do you have for project managers who are in the process of becoming scrum masters?

We do not advise that; the “experiment” of trying to use ex-project managers as scrummasters has been tried many, many times, and has been usually not successful, since there is almost no overlap in skills/experience, since a scrummaster is working to change the organizational design to real scrum (which eliminates the role of project manager), since the scrummaster is not responsible for the product or release, and since the scrummaster has no power over teams. That’s a dramatic change of role and responsibility. In organizations that are adopting real scrum, the structure becomes very flat (with few manager roles remaining) and project managers usually leave and go to another organization that is still traditional or is adopting “scrum, but…” or “fake scrum.”

Who makes the best scrum master?

People who are not interested in power, control, or project leadership, and who have the courage to openly advocate for and explain to leadership the dysfunctions in the current organization and the dramatic structural changes that will be necessary (such as the elimination of all single-function groups such as test group, analysis group, the elimination of project management groups, and so forth). People who are less interested in their own career “progress”, but more interested in organizational design, systems optimization, challenging the status quo, and fostering real teams in self-managing organizational culture.

Past videos of Craig:

Craig’s workshop has limited seats, go ahead and book before it is sold out: 
http://booking.agilefaqs.com

 

Agile India 2013 – Theory of Constraints Thinking Processes by James Ross

James Ross is a Senior Engineering Manager at Aconex. He is a popular speaker at various Agile conferences, including Agile India 2012 and Agile Australia 2012.

James has been leading agile development teams for a decade and has long since stopped believing that agile is the point. He has played consultant, architect and development manager roles at various organisations. His interests of late have been the Theory of Constraints, Systems Thinking and sustaining conversations with business people that the business people find interesting.

He will be holding a workshop on ‘Theory of Constraints Thinking Processes’ at Agile India 2013. We interviewed him recently and asked him several questions about his special interest in the theory of constraints and its practical applications.

What triggered your interest in the Theory of Constraints Thinking Processes?

As an avid reader and an agile practitioner since 2001, it’s only natural that I stumbled upon the theory of constraints. I seem to recall a colleague at ThoughtWorks mentioned it in passing in around 2004 and I started like most people by reading “The Goal” by Dr. Eli Goldratt, the inventor of TOC. Although it won’t win any literary awards as a novel, I found his style of questioning deeply held assumptions as a fundamental way to get to breakthrough improvements in any system very interesting indeed. I went on to read the next book, “It’s Not Luck”, which introduces the formal TOC Thinking Processes, which, to be honest, seem to be largely unknown even by people who are familiar with TOC generally. This is a pity, because in many ways they are much more immediately and practically useful to individuals at any level or role in an organisation. A few years later I stumbled upon the only tool I am aware of that is specifically designed to help you create TOC Thinking Process Diagrams. It’s called Flying Logic, and its user guide was the best education in the Thinking Processes that I had come across and from there I started using them for real to help with planning, collaboration, change management, problem diagnosis and conflict resolution. I am quite convinced I will use them for the rest of my life no matter what I end up doing. They transcend agile, software development and business; they are truly universally applicable.

Can you give us an example of the practical application of these thinking processes?

Absolutely. A specific tool in the TOC Thinking Processes is the Current Reality Tree. It’s the tool you use in circumstances where others might turn to The 5 Why’s from Lean. Although the 5 Why’s is simple and easy to use, it tends to oversimplify things a bit too much by encouraging single-cause thinking and ignoring the fact that chronic problems are held in place by reinforcing loops. A Current Reality Tree is a tool you turn to when diagnosing any problem. You start with the negative effects that you observe and work back through their causes, which often need to combine to result in the problem and often feed back on each other. At each stage, assumptions about causality are questioned (there is a formal way of doing this in TOC) so that speculation is removed and the true root causes of problems can be found. Once you learn how to use one, the 5 Why’s will seem very weak in comparison. The main reason is that if you see only a single cause for your problem, you have only one way to solve it. But if you realise three independent things had to happen to result in your problem, stopping any single one of them will solve your problem. This gives you three ways to solve it and you can just pick the easiest. So it seems more complicated but actually makes things easier. This is a recurring theme in all of TOC.

What is the take away for the attendees of the workshop?

People who attend this workshop will get a chance to apply these very practical tools to some problems of their own and to some ambitious goals of their own. They will learn how to diagnose the present and to create a better future for themselves and for their organisations by being collaborative and respectful with their colleagues and holistic in their thinking. They will learn that conflicts can be resolved in a win/win way with a concrete approach that they can apply in their work and life immediately after the workshop. Like many good things in life, these tools are simple to learn but take a life time to master!

Past talks:

Why Nothing You Ever Do Might Make the Slightest Differencehttp://bit.ly/SZqL17

Sounds like another interesting workshop at Agile India 2013, book soon to avoid disappointment: http://booking.agilefaqs.com 

 

Agile India 2013 Registration Trend Compared to Agile India 2012

Even though we have 3 more months for the Agile India 2013 conference, the registrations this time has been crazy. But how crazy is really the registration compared to Agile India 2012 Conference?

So I pulled out the stats and looked at the trend graph of what it look for 2012 vs. 2013.

Following is the comparison:

Agile India 2013 Registration Trends

Yes, as you can see, we are off to a flying start (registration openned almost 3 weeks ahead) and  the Agile India 2013 conference is almost 2 weeks later compared to Agile India 2012 conference.

Agile India 2013 – Attendees Profile (as of Dec 7th)

Over 558 delegates have registered for the Agile India 2013 Conference so far.

We’re happy to announce that we’ve participants from over 56 companies participating in the conference:

Aconex India Pvt Ltd Alcatel Lucent India Alliance Global Services India Pvt. Ltd.
Allscripts India Pvt. Ltd Aricent Technologies BNP Paribas India Solutions
Cisco/NDS Cognizant Technology Solutions CSC
Dell India R&D Centre Direction Software Solution Dual Nations Software Services LLC
eGain Communications Pvt. Ltd. Enteleki Technology Solutions Envestnet, India
Equal Experts Ericsson Exelplus
Exilesoft (Pvt) Ltd GembaTech HCL Technologies
Huawei Technologies IIIT Bangalore Independent Consultant
InMobi InRhythm Inteamo
Intergraph Consulting Pvt. Ltd. John Deere India Pvt Ltd MailOnline
Monsanto India IT MSCI Multunus Software
OneShield Inc Ostrya Labs Pitney Bowes Software
Rikner.com Rotary International Infotech Pvt. Ltd. S.I. Systems
Sabre Holdings Sabre Travel Technologies SAP Labs India Pvt. Ltd.
Schneider Electric India Shop Smart Inc/BradsDeals.com Societe Generale
Software Artisan SSN College of Engineering Support.com
Symphony Teleca Corporation Synerzip Softech Inida Pvt. Ltd. Tata Consultancy Services
TenXperts Technologies Thomson Reuters ThoughtWorks Technologies India Pvt. Ltd.
Yahoo India Pvt Ltd Yellowtail Software

And they play the following 70 distinct roles:

Agile & IT Process Consultant Agile and Lean Coach Agile Coach
Agile Coach/Scrum Master Agile Head Coach Agile Project Manager
Architect Assistant manager – quality Assistant Professor
CEO Co-Founder and CEO Code Junkie
Code Monkey Consultant Delivery Manager
Development Manager Director Director-Quality
Director, Wireless Division Engineer 2 Engineering – Director
Engineering Lead Engineering Manager EVP & CTO
Executive Manager General Manager General Manager – Quality
Group Manager Group Project Manager Head of Engineering
Head of Project Management Lead – Development and Testing Lead Executive Quality
Manager Manual QA Engineer Operations Manager
Product Owner Product Owner/Technical Lead Program Manager
Project Manager Project Quality Manager Projects Manager
Release Manager Senior Agile Project Manager Senior Consultant
Senior Director Senior Engineer – QA senior executive – quality
Senior Manager Senior Manager – Consulting Senior Manager-Technical Group head
Senior Manager, Agile Coach Senior Project Manager Senior Software Engineer
Software Architect Software Artisan Software Developer (Embedded System)
SR ASSOCIATE Sr Engineer Sr. Manager
Sr. Manager – Projects Sr. Project Manager Sr. Quality Manager
Sr. Software Engineer1 Sr. Vice President Team Lead
Technical Architect Technical Leader / Scrum Master Technologist
VP Solutions

Continuous Delivery Workshop by Jez Humble @ Agile India 2013

Jez Humble (@JezHumble) is a Principal Consultant with ThoughtWorks, and co-author of Jolt Award winning book Continuous Delivery (http://continuousdelivery.com/). He got into IT in 2000, just in time for the dot-com bust. Since then he has worked as a developer, system administrator, trainer, consultant,  manager, and speaker. He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies.

Jez Humble

His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices in the field of Agile delivery.

Continuous Delivery

He will be running a one day workshop at Agile India 2013.  This week we spent some time with Jez and chatted to him about continuous delivery, a topic he is very passionate about.

1. How does continuous delivery improve collaboration between developers, testers, and operations?

Continuous delivery improves collaboration between everybody involved in software delivery by requiring it. It’s impossible to achieve high quality systems without developers and testers physically working together, and without developers being accountable for how the systems they build perform in real life. When testers work in silos physically separated from developers, quality always gets worse. When operations work in silos and don’t collaborate with developers, deployment is always going to be a high-risk, painful activity.

2. How do you sell the benefits of continuous delivery to clients who have infrequent releases?

The HP LaserJet firmware team just brought out a book that describes how they implemented continuous delivery: “A Practical Approach to Large-Scale Agile Development“. Obviously you don’t ship new firmware that often, but implementing continuous delivery provided enormous benefits for them. They measured team activity over the three years it took them to implement continuous delivery and found it reduced development costs by 40% and increased the amount of time the teams were spending on feature development (as opposed to non-value-add activities such as integration and manual testing) by a factor of 5. They implemented continuous integration and extensive test automation – they have 30,000 automated functional tests that run in virtual and emulated environments on logic boards – and if somebody checks in a change to version control that breaks the tests, the change gets automatically reverted straight back out of version control. The most important benefits of continuous delivery are second order – giving developers fast feedback so they can take responsibility for their actions, so they get rewarded for delivering work that is integrated, tested and production-ready, rather than “dev complete”. That forces teams to architect their systems with automated testing and deployment in mind, and to perform those activities frequently from early on. If you’re doing it right, you completely remove the integration and testing phase – your software is in a deployable state from day 1 of the build phase, which means releases are low risk, you can get feedback much more quickly and avoid working on features that aren’t valuable to your customers, and you can measure your progress and identify risks in a transparent way.

3. What are some of the challenges teams face when adopting continuous delivery?

The main challenges to adopting continuous delivery are organizational and architectural, and these two problems are tightly coupled (which is what Conway’s Law tells us). It’s usually best to start with continuous integration, which means every developer is checking in to trunk at least once a day, we build and test the complete, integrated system every time a change is made to version control, and if there is a problem everybody pays attention and we prioritize fixing it straight away. Doing everything in that one sentence is still a tall order for most organizations. Often there aren’t enough automated tests, the ones that exist are flaky, they’re expensive to create and maintain, and nobody cares much if they fail. Production-like integration environments are often expensive to provision and hard to get access to. Developers don’t work on trunk because it slows down the rate at which they can declare their crappy, buggy, undeployable code “dev complete”. It’s hard to retrofit automation to systems that aren’t designed for it, and it’s hard to retrofit CD into silo-based organizations. So adoption is usually impossible unless management is bought in and at least some of the engineers are willing to change the way they work. It’s always the organizational issues that kill you in the end.

4. What is the take away for the attendees of the workshop?

The low-down on how to implement continuous delivery in real life, even in large, distributed organizations. I cover everything from continuous integration to patterns for low-risk releases, with material on automated infrastructure management, managing databases, and how to create maintainable suites of automated acceptance tests. I also discuss organizational issues and the value proposition so practitioners are equipped to talk to their management. That’s a lot of ground to cover so there’s no hands-on coding, but the advantage is that it’s at a high enough level that anybody can benefit – developers, infrastructure people, dbas, managers, testers. One of the benefits is that just by getting all those different roles into one room, we can get an appreciation for the problems we each face, which usually leads to some interesting discussions.

Like all other workshops, this workshop has limited seats. Book soon to avoid disappointment: http://booking.agilefaqs.com

Past Talks: http://continuousdelivery.com/talks/

Kanban Primer Workshop by Masa Maeda @ Agile India 2013 Conference

At Agile India 2013, we are offering 14 workshops, all under one roof from 16th February to 2nd March. This is a unique opportunity to learn from experts all over the world, don’t miss out! One of the workshops we will be running is titled ‘Kanban Primer’, by Masa K. Maeda.

Masa is the creator of Lean Value Innovation, he is an internationally recognized expert on Lean and Agile Project Management, Kanban and Scrum. He started Valueinnova in the Silicon Valley California in 2008.

He has spoken at several conferences including Lean Kanban and Agile India 2012. He was one of the favorite speakers at Agile India 2012 based on the feedback we received.

Masa Maeda

We stole some of Masa’s precious time and quizzed him about Kanban and its benefits.

1. What are key benefits of Kanban over the first generation agile methodologies like Scrum?

Kanban is a fabulous practice that is equally applicable to technical teams and to management and leadership teams. The biggest benefit of Kanban is that it brings an amazingly effective way to improve process and to generate a culture of continuous improvement with very minimal effort. It is also fun to do. It accomplishes this by being highly adaptive and improving value flow over existing processes. This is great news because it means Kanban is equally applicable to organizations doing Waterfall, Scrum, XP, or other. Yes, this means it also helps improve value generation and delivery over other agile methodologies. It also means it can be applied beyond IT and software development. Some people think Kanban is only good for IT work but that isn’t actually so. We have applied it very successfully to Software Development, Admin, HHRR, Healthcare, Education, Telecommunications, etc.

2. Is it possible to introduce Kanban into an an organization this is already practicing Scrum/XP?

Definitely yes. Kanban is compatible with other methodologies. It actually helps improve the performance of Scrum and XP teams. Kanban has been proven to actually make it easer for agile adoption to spread more easily and more quickly. One example of how it helps improve Scrum is by improving the flow of Stories and also by bringing an effective way to handle urgent tasks. For XP teams it allows to better visualize the work to do and being done, aligning better the dev-test activities as well as the UAT. In both cases it increases customer satisfaction because value delivery improves over time.

3. Who is the workshop intended for?

It is equally good for executives, managers, and team members. Executives benefit using Kanban, for example, to manage their business and customer portfolios, and by reducing time-to-market. Managers benefit because Kanban gives them visibility and predictability over projects; and by reducing delivery time through continuous improvement. Team members benefit because it increases autonomy, effectiveness, and quality. It is important to understand that Kanban is not a technical practice but rather a discipline to improve what we currently do, be it technical or managerial.

4. What is the key take away for the attendees?

 This workshop will allow them to get enough knowledge to get started with Kanban. They will have the bases of its system and the method itself. This means they will be able to figure out how to create an effective Kanban board, generate the key elements to have high visualization, to do root-cause analysis and to effectively increase value flow. The workshop is highly interactive through lots of team exercises. It will be a fun day. Our training typically gets the highest scores during evaluations because of its format and because of the amount of knowledge and understanding acquired by the attendees.

Past talks: Lean Value Innovation – Agile India 2012

Seats are limited for this workshop, book soon to avoid disappointment: http://booking.agilefaqs.com

Architecture with Agility Workshop by Kevlin Henney @ Agile India 2013 Conference

Kevlin Henney is an author, presenter, and consultant on software development. He has written on the subject of computer programming and development practice for many magazines and sites, including Better Software, The Register, C/C++ Users Journal, JavaSpektrum, C++ Report, Java Report, EXE, and Overload. He is a member of the IEEE Software Advisory Board. Henney is also coauthor of books on patterns and editor of ’97 Things Every Programmer Should Know’.

Kevlin's Books

Henney has given keynote addresses at a number of conferences, including ACCU, DevWeek, Embedded Systems Club, GeeCON, GOTO, JAOO, Jfokus, NLUUG, OOP, PHPNW, SDC, Software Architect, and XP Day.

We are really excited to have Kevlin present his workshop on ‘Architecture with Agility’ at Agile India 2013.

Kevlin Henney

This week we interviewed Kevlin and got some more information about his workshop.

1. Agile practices talk about emergent design and iterative production, how does architecture fit into this model? Is agile architecture emergent?

Process influences and is influenced by what you build and what you can build is influenced by process. Software architecture can best be considered the set of significant design decisions, where significance relates to cost and difficulty of change. Agile projects that do not consider their architecture are not likely to remain agile for long. If an agile project focuses on delivering functionality at the expense of a design that supports incremental development, it will find itself struggling to deliver functionality. Of course, what constitutes a significant design decision is not obvious up front, so establishing an architecture is necessarily a dynamic that flows through the whole development rather than a fixed activity locked into an early phase of development. Architecture embodies knowledge, knowledge is acquired by learning and learning takes time; a development process structures this time.

2. What are some of the misconceptions about agile architecture?

The most obvious misconception is that a good architecture will just happen and emerge miraculously from a succession of iterations, without focused responsibility and effort. Agile architecture requires guidance and nurturing, shaping a system through a succession of changes, each considered to be an experiment against a hypothesis, each considered to be open to review and change.

3. What is the key take away for the attendees from the workshop?

An architecture will constrain or enable the process of development. If you want to be agile, want to make changes frequently and sustainably, want to deliver and get feedback more often, then you need an architecture that supports rather than frustrates such a process. And, like most things in life, if you want good architecture, you have to care about it.

Past talks by Kevlin:

Kevlin’s workshop has limited seats so go ahead and book at http://booking.agilefaqs.com before it is too late!