Agile Thoughts

I think you get the idea--there are a lot of different scaling Scrum frameworks.  How to effectively scale Scrum from a single team to hundreds is the big question many in the industry are trying to solve.  

The post 050 Introducing the Scaling Agile with LeSS series first appeared on Agile Thoughts.

I think you get the idea–there are a lot of different scaling Scrum frameworks.  How to effectively scale Scrum from a single team to hundreds is the big question many in the industry are trying to solve.

Scrum is a lightweight framework discovered in the eighties in response to accelerating demands on building new products faster.  Scrum didn’t have a clear way to scale across hundreds of people working on one product.  Now that Scrum has crossed the threshold from being an early adopters software development methodology into being the mainstream way of organizing software teams, large scale enterprises are interested in the question: How to effectively do Scrum with multiple teams?

Today there are more than dozens of scaling Scrum and Agile frameworks.  In this series we’ll look at some of these frameworks to get an understanding of the philosophy behind them and how are they differ. First, we’re starting with the Large Scaled Scrum framework known as LeSS.  In many of these episodes I was able to interview the founders of LeSS, Bas Vodde and Craig Larman.  Why am I starting with LeSS?  As a writer, I realized a natural a sequel to Agile Noir, would be to write another business novel about scaling.  Grande Noir is the working title.  So I started doing research through talking to other IT consultants I knew and tried to find out what frameworks they were using and what frameworks made them happy.  Although LeSS isn’t the most popular scaling framework, the people behind LeSS convinced me that LeSS solved a lot more of the problems that companies face when undertaking scaling Agile.  Other scaling frameworks, such as the well known SAFe, tended to proscribe additional layers of management or process.

Next Episode, we’ll travel to sunny California’s Bay Area and to talk with Bas Vodde about “Why do people want scaling?”

If you’re listening to this in 2018 and it’s not yet April, Craig Larman is teaching a LeSS class this April 16th in Seattle, and I’ll be attended to further soak in more ideas to use in writing Noir Grande.  So if you attend, be sure to say “hi.”  If you have something you’d like to share with the listening audience of Agile Thoughts, we’ll make some arrangements as I’ll be bringing recording equipment.  For more information about LeSS and more timely information about LeSS trainings, courses, and events, surf over to http://LeSS.works.  They’ve got events happening all around the globe.

Let's say your job was to write a program that types to the screen the word: AWARE.

The post 011 The Old Way isn’t Sustainable first appeared on Agile Thoughts.

Let’s say your job was to write a program that types to the screen the word: AWARE.

If we skip TDD, we just build our program to output the letters A, W, A, R, E, and we’re done.

Well, guess what? We aren’t done because a good developer realizes feedback is needed to prove the program works. So they run the program at least once to observe that it works. They may even confirmed their understanding of the spelling by looking at a dictionary or 1asking a colleague, and then publish the program.  Great!  Notice in even this simple example there is a problem–the developer did *manual* testing when observing the result to decide if the program worked. Two months later, a different programmer is asked to add a colon to the end to make the meaning clear.  They develop the code and again, manually look at the word “AWARE:” probably coming to the same understanding of the spelling as the previous developer, and then they publish the code.  However, often, the later developer is focused on only the colon at the end because that was their contribution. This third developer notices t

Over the last twenty years the Agile revolution which used to be edgy and alternative is now mainstream with most teams in the IT industry using Scrum and Kanban. You may not have realized that although those two popular lite weight frameworks are valuable changes, they don't at all address how to construct code that supports frequent delivery.

The post 010 Agile and TDD Neglect first appeared on Agile Thoughts.

Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.

Today is the future. [echo, jetsons sounds or future sounding music] The world has been marching forward but still there are no flying cars.  [whawha wha..] Well, there are flying cars but none mass produced. Why not? Are We developers and we managers part of the reason why we still don't have such nice things?  Is the low quality track record of IT to blame?  Must we be used getting patches, and upon installation, hoping this new version doesn't make things worse?  

The post 009 Introducing the Test Driven Development series first appeared on Agile Thoughts.

Today is the future. [echo, jetsons sounds or future sounding music] The world has been marching forward but still there are no flying cars.  [whawha wha..] Well, there are flying cars but none mass produced. Why not? Are We developers and we managers part of the reason why we still don’t have such nice things?  Is the low quality track record of IT to blame?  Must we be used getting patches, and upon installation, hoping this new version doesn’t make things worse?

Lancer has taken a journey into the internet, companies, meet ups, and bars to find out why TDD is not yet mainstream.  In upcoming episodes we’ll cover what TDD is, hear from developers why they don’t TDD, and hear from managers what they see as the problem. We’ll also cover how to do TDD, what the project characteristics look like when TDD is working, and early warning indicators of failed adoption. And finally we’ll cover how to start doing TDD as: a developer, a team lead, a manager, and as a director.

Developers who actually do TDD are rare, like unicorns and flying cars.  So if you like the idea of flying cars, and like me, are unsatisfied being tied to the earth whenever you want to go somewhere, then take a deep look within yourself as you may be part of the holdup.  We all complain that the other person’s or company’s software quality is low because every other release something that used to work, stops. That is a test automation problem. That shiny flying car we all want, the code that operates it is going to need a good micro test suite. By each of us being quick to hop to the latest “something.io” library yet unwilling to spend much effort to learn something as powerful as TDD, we’ll never get our flying cars because you and your passengers will be tits up in a shallow impact crater when the software stops working.

​

The post 008 The Conductor—Continuous Integration first appeared on Agile Thoughts.