Verrassende stadswandeling door minder bekende delen Florence

Uiztciht op Dom en Campanille vanuit Bobolituinen FlorenceNa de stadswandeling met onze dochters op maandag langs de bekende toeristentrekkers in het centrum van Florence, hebben we voor vandaag afgesproken met z’n tweeën, dus zonder dochters, terug te keren naar Florence voor een volgende stadswandeling. Ook buiten het drukke centrum zelf is er genoeg te zien. Vanwege de warmte zijn we vroeg op pad. Om 7.30 vertrekken we uit Lamporecchio, een uur later starten we de GPS voor de wandeling vanaf Porta la Prato.

Oltrarno en Bobolituinen

Zicht op Oltrarno en Arno Florence

Zicht op Oltrarno en Arno Florence

We trekken eers langs de Arno, om over te steken en bij San Frediano in Cestello de eerste kerk te bezichtigen. Klazien heeft haar wikkelrokken mee om desgewenst haar ontblote benen en armen te kunnen bedekken. In veel kerken wordt dit op prijs gesteld. Deze kerk is vrijwel verlaten, alleen een paar schoonmakers doen er hun werk.

De Brancaccikapel is de volgende kerk in dit stadsdeel. Dan even wat anders. We lopen over de Via de Serragli. De ingang naar de Giardino Torrigiani zien we niet, of het is toch die als een privéterrein afgeschermde opgang bij een huis geweest. We lopen door, verbazen ons over de enorme houten deuren in de Porta Romana en gaan linksaf naar de Giardino di Boboli, ofwel de Bobolituinen. Volgens de Capitool gids moet de schoorsteen van de 3-7 full-time werkzame tuinieren ook roken, en dus wordt er entree gevraagd voor deze enorme publieke tuinen. €10 p.p. is fors, zeker als Klazien vervolgens – gewend aan de fraai aangelegde tuinen in het Berlijnse Sansoucci, of de paleistuinen van het Apeldoornse Het Loo terugdenkt – door het park sjouwt op zoek naar echt indrukwekkende groenvoorzieningen.

Beelden in Bobolituinen 7

Eén van de klassieke veelden in de Bobolituinen

Diverse delen van het park zijn in onderhoud en zo niet toegankelijk. De orangerie zit dicht, de vijver rond L’Isolotto vol gifgroene algen. Menig klassiek beeld langs de Viottolone is verweerd. Apart is een porseleinmuseum aan de noordoostzijde. Selfie-sticks mogen niet mee naar binnen. Die worden buiten bij de noordelijk gelegen uitzichten op de binnenstad en het Pitti paleis volop gebruikt. Langs de Neptunus- en Ganymededsfontein lopen we via het Amfitheater door naar La Grotta Grande. Van dichtbij is het interieur, de gietvormen van Michelangelo’s Vier Slaven, Vincenzo de Rossi’s Paris en Helena en de Badende Venus van Giambologna indrukwekkend. Een klassiek onderonsje.

Centrum Oost

Klazien met zicht op Ponte Vecchio Florence 2

Klazien met zicht op Ponte Vecchio Florence

De Ponte Vecchio weer over, rechtsaf langs het water. Natuurlijk maken ook wij nog een foto met uitzicht op de brug. We zijn blij niet in de rij voor het Uffizi te hoeven aansluiten. Wat verderop ligt het enorme Piazza di Santa Croce. De Santa Croce basiliek heeft net als de Dom een indrukwekkende façade en trekt z’n publiek. Zelf zigzaggen we verder naar het Piazza dei Compi. De overdekte zuilengalerij bij de markt is fraai geschilderd, maar wat een contrast met het naastgelegen geasfalteerde parkeerterrein. We rusten er kort.

Centrum Noord

Grote Synagoge Florence

Grote Synagoge Florence

We bekijken de Santa Ambrogio kerk, die nergens in de gids staat beschreven. In de straat ernaast, maar we hebben een blokje om nodig, om de ingang te vinden, staat de Grote Synagoge. Helaas moet ook hier €6,50 p.p. entree betaald worden zonder te mogen fotograferen. We houden het bij een kiek door het hek heen.

Kandelaren in Santissima Annunziata kerk Florence

Kandelaren in Santissima Annunziata kerk Florence

Kerken en arcades vind je rond het Piazza della Santissima Annunziata. We bekijken de gelijknamige kerk en de zuilengang ernaast. De San Marco kerk bekijken we ook, het museum laten we schieten. Via het Piazza delll’ Indipendenza en Piazza del Crocifisso gaan we naar het Fortezza da Basso. Naar binnen kunnen we niet. Zo te zien is de binnenplaats ook volgebouwd met minder bezienswaardige zaken. Aan de buitenzijde van het fort stromen de auto’s en treinen van en naar het Stazione Centrale di Santa Maria Novella voorbij. Zelf pakken we de Viale Belfiore om naar Porta la Prato door te stappen en na weer ruim 16km wandelen en kletsnat van het zweet te zijn te gaan genieten van de airco op de terugweg.

When and how can Large Scale Scrum (LeSS) help you spread agility throughout the enterprise?

xLeSS-logo.png.pagespeed.ic.OfkLPOKrjcWhereas Scrum is single team oriented, Large Scale Scrum (LeSS) literally scales up the activities in Scrum, applying them at the team-of-teams level. For example ‘large-scale planning’ is done by delegating one or two members from each team to this higher-level team. Retrospectives and Scrum-of-scrum problem solving is done in the same way. Beyond the teams LeSS adds open space, town hall meetings and other coordination and communication activities.

Rather than asking, “How can we do agile at scale in our big complex organization?” a different and deeper question is, “How can we have the same simple structure that Scrum offers for the organization, and be agile at scale rather than do agile?” This profound insight is at the heart of LeSS (Large-Scale Scrum).

The framework

principlesAt its core, it’s Scrum with a Scrum master, Development team and Product owner. As stable team it grows into a Feature team. As other agile methods, LeSS is based on Lean thinking and systems thinking. Get rid of waste, improve continuously. What you do and with whom does matter, because of inter-dependencies, team building and a 360 degrees focus on a whole product with customer-centricity.

LeSS organizations tend to follow a simple structure. Work is organized around teams, and mismatch of skills triggers learning and coordination within existing teams. Feature teams scale nicely, but when their number goes above 8 teams additional structure is needed. Requirement areas provide this structure and complement the concepts behind feature teams. A requirement area is a categorization of the requirements, managed by an Area Product Owner, leading to different views of the Product Backlog.

Attention is given to architecture and design, technical excellence, and continuous integration to add value to Scrum.

Case studies are published on the LeSS website, ranging from Agfa Healthcare, BMW Group to Nokia, Port of Rotterdam and UBS.

LeSS is more, or More with LeSS

The formal LeSS Rules for 2-8 teams fit on the front and back of a page; the version for product teams of up to 1,000 people, LeSS Huge, is not much larger. LeSS has been around for a decade now. Bas Vodde and Craig Larman wrote two initial books on LeSS based on first-hands experiences with clients adopting the approach, and are to publish a third one this month:

Well, why read three books, if you can avoid the first two and only read the last, hopefully most mature one? What to expect? The book is organized into four major sections:

  1. Stories of groups going through a Sprint with LeSS, to illustrate the structure and practices during a Sprint.
  2. Structural aspects: Guidance on how to adopt LeSS, the hows, whats, and whys of organizing by customer value, and the role of management and Scrum Masters in LeSS.
  3. Product aspects: How to define the product (which may be different than your current scope), the role of Product Owner when scaling, and some implications in large-scale development on the Product Backlog and Definition of Done.
  4. Sprint aspects: How to do a Sprint in LeSS when there are many teams working together to ship a common product, from Sprint Planning to Retrospective, and from coordination and integrationguidance to technical excellence guidance.

About the creators

Craig Larman is a management and product development consultant in enterprise-level adoption and use of lean development, agile principles and practices, and large-scale Scrum in large, multisite, and offshore development. He is chief scientist at Valtech, an international consulting and offshore outsourcing company. His books include the best-sellers Agile & Iterative Development: A Manager’s Guide (Addison-Wesley, 2004) and Applying UML and Patterns, Third Edition (Prentice Hall, 2005).

Bas Vodde works as an independent product-development consultant at Odd-e and large-scale Scrum coach. For several years he led the agile and Scrum enterprise-wide adoption initiative at Nokia Networks. He is passionate about improving product development, an avid student of organizational, team management, and product development research, and remains an active developer.

LeSS versus SAFe

30-31 August – Large Scale Scrum Conference Amsterdam

In this 2 days conference in De Rode Hoed, Amsterdam there are experiments and experiments teams and communities, LeSS booths, fellow practitioners. You can Join the LeSS founders for two days of sharing and learning about Scrum at scale. All about the event programme and tickets (which are sold for only €250) can be found online.

 

Julie Fisher – Importing Democracy

importing democracyIn Importing Democracy, Julie Fisher explores how democracy is developing in South Africa, Tajikistan, and Argentina. She uses Robert Dahl‘s definition of democracy including three dimensions – political opposition, public participation, and law-based civil liberty. Fisher’s focus is on non-governmental organizations (NGOs) contributing to these dimensions, instead of governmental initiatives, like the United States invasion of Iraq and failed export of democracy to that country. The historical, political, and economic context of each country is described. General contours of civil society, then the role of democratization NGOs in promoting both loyal opposition and law-based civil liberties are addressed. Following the nine country chapters, the book concludes with a comparative overview and implications for international policy.

Each of the three countries have a different starting point, set of democratization forces, and outlook. South Africa is promising. Many Tajik NGOs are weak, but there is evidence that they do well when they concentrate on Tajikistan’s strongest local democratic traditions and institutions. Although Argentina is lacking words for accountability, much less legal accountability, democratization NGOs help strengthen government institutions at both the local and national levels. The author is open-minded and critical of the influences of AIDS and poverty, ad Peronism. The fate of democratization ultimately depends on the state, on civil society, and on the relationship between them.

The many names and examples in the book will not be remembered by heart, the main findings, conclusions and recommendations are far more important. The book provides insight in the inner workings and practical consequences of the active role NGOs play in further democratization of countries.

About the author

Julie Fisher is passionate about democracy, linked as it is to improved economic performance, increased equality, political stability, good governance and the avoidance of war. However, democratization is also, according to Julie, a long, hard slog. In her latest book, Importing Democracy: The Role of NGOs in South Africa, Tajikistan and Argentina, she shows how democratization NGOs…an ignored global trend and take on this giant challenge, not just in the three countries where she conducted over 100 interviews, but in other countries as well. Before joining the Kettering Foundation, Fisher was a Scholar in Residence at the Program on Non-Profit Organizations at Yale University and a lecturer in the Biology Department for a course on World Population. She previously taught comparative politics and a course called. The Politics of Third World Development; at Connecticut College. As a specialist on nongovernmental organizations and microenterprise development, she has been a consultant to numerous international agencies, including CIVICUS, Technoserve, CARE, Trickle Up, Lutheran World Relief and Save the Children. She is the author of The Road from Rio: Sustainable Development and the Nongovernmental Movement in the Third World (Praeger: 1993) and Nongovernments: NGOs and the Political Development of the Third World (Kumarian: 1997). Her first book was translated into Spanish and published by the Fondo de Cultura Económico in 1993. The second was translated into Chinese and published by Tsinghua University in 2002. Fisher has been a member of the Advisory Board for the Civil Society Series published by the New England University Press. She often reviews articles for the Nonprofit and Voluntary Sector Quarterly and Voluntas. She was a speaker at Working Abroad: Opportunities in the Nonprofit World. July 7-8, 2011, University of Colorado Denver, on The Work of Americans Abroad. Fisher received her B.A. in international studies at Pomona College, in Claremont, California. She received her M.A. and Ph.D. degrees from the Johns Hopkins School of Advanced International Studies in Washington, DC. The author and her husband, a retired historian specializing in Russia, live in Maine.

When and how can Disciplined Agile Delivery (DAD) help you spread agility throughout the enterprise?

Disciplined Agile Delivery (DAD) presents itself as a Process Decision Framework for Enterprise I.T. Scott Ambler (Scott Ambler + Associates) developed the framework, now distributed through the Disciplined Agile Consortium. It’s non-proprietary, free, and non-prescriptive. Ambler previously worked with IBM Rational and Ambysoft.

“The Disciplined Agile Delivery (DAD) process decision framework  is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.”

At a glance

  • Goal-driven
  • Enterprise aware
  • Work closely with enterprise professionals, such as enterprise architects and portfolio managers.
  • Adopt and follow enterprise guidance.
  • Leverage enterprise assets, including existing systems and data sources.
  • Enhance your organizational ecosystem via refactoring enterprise assets.
  • Adopt a DevOps Culture.
  • Share learnings with other teams.
  • Adopt appropriate governance strategies, such as the ones described here, including open and honest monitoring.
  • Risk and value driven
  • Focus on consumable solutions instead of just working software

Interesting aspects

DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling, eXtreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.

It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all.  Instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach.

In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.

The Disciplined Agile Manifesto

The original Agile Manifesto (2001) was extended for DAD. The rationale is the broader picture. So no focus anymore on software or development teams.

We value:

  • Individuals and interactions over processes and tools
  • Consumable solutions over comprehensive documentation
  • Stakeholder collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, disciplined agilists value the items on the left more.

The Principles Behind the Disciplined Agile Manifesto

  1. Our highest priority is to satisfy the stakeholder through an early and continuous delivery of valuable solutions.
  2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Stakeholders and developers must work together daily throughout the project.
  5. Build teams around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a delivery team is a face-to-face conversation.
  7. Consumable solutions are the primary measure of progress.
  8. Agile processes promote sustainable delivery. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
  14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
  15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.

More roles than in Scrum or XP…not simply an extension of Scrum

It brings architecture, product management, and portfolio management together. Combined with the competencies of IT staff, Retrospective results (Lessons learned), and IT intelligence (metrics) input is given to the DevOps, in which – strangely enough, processes for IT delivery / Change, and IT maintenance / Run still have their own processes.

DAD has a work item stack instead of a product backlog, a more detailed view on possible techniques to be used for changing requirements while constructing. DAD has its own terminology, so it’s not simply an extension of Scrum. It presents several possible workflows.

Here is how DAD moves beyond Scrum:

  • Deliverables: Scrum delivery concentrates on “working software,” while DAD deliverables focus on a “complete, end-to-end solution.”
  • Style: Scrum is more prescriptive; DAD is pragmatic and thus easily tailored.
  • Phases: Scrum focuses on the construction phase, but DAD focuses on the inception to construction through to transition.
  • Scalability: Scrum targets moving from a single team to multiple teams; DAD is scalable from a single team to the enterprise. DAD talks about Lean development in its scaling method; the system can be optimized as a whole by eliminating non-value-added activities and building quality from within.

DAD also adopts a visualization of the Kanban workflow to measure and manage the flow of work by limiting work in progress. DAD focuses on Scrum in the construction phase, as iterative and incremental delivery can be measured with Scrum rules, disciplines, and practices.

DAD also brings XP engineering practices into the construction phase to reduce the feedback cycle and get the code cleaned up faster.

Certification

The certification levels reflect a Shuhari philosophy and are comprised of Disciplined Agilist, Certified Disciplined Agilist, Certified Disciplined Agile Practitioner and Certified Disciplined Agile Coach. The certification roadmap page overviews the complete strategy.

Supporting tools

Tools supporting Disciplined Agile Delivery:

Books:

When and how can Scaled Agile Framework (SAFe) help you spread agility throughout the enterprise?

Scaled Agile Framework (SAFe) already has its version 4.0. It delivers in their own words “knowledge for the people building the world’s most important systems.” The popularity of Dean Leffingwell’s Scaled Agile Framework (SAFe) makes finding training or consulting easily. There are plenty of articles, tutorials and videos online, and the certification process is clear and fairly mature. Leffingwell wrote Scaling Software Agility with best practices for large enterprises. It led to SAFe.

In November 2016, Leffingwell’s new book, SAFe® 4.0 Distilled: Applying the Scaled Agile Framework® for Lean Software and Systems Engineering will be released.

Relatively easy for organizations to transition to, SaFE is also prescriptive – it tells organizations exactly what to do. A pitfall is the to try to adopt all of it without understanding the advantages of every piece of SAFe. It could lead to new mantras and language, including teamwork, program work, business epics, technical epics, metrics at every level and a host of other requirements, without a clear rationale. Complexity then ruins the simplicity which is core to Agile.

A fool with a tool is still a fool

Introduction to SAFe

Because the Scaled Agile Framework‘s home page or overview posters may be overwhelming, I took this SAFe in a nutshell from a Henrik Kniberg presentation.
safe in a nutshell
A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end: requirements, coding, testing, and deployment. Several teams create what SAFe calls a release train, which organizes around a program. That’s a single project, or at least, one program-of-projects. It has a single line item in a budget – the company is buying one specific thing. This is the small project the executive talks about.

In SAFe terms, the Release Train is the team-of-teams, typically 50–125 individuals. Like a real train, the release train runs on a schedule, though that schedule can be as flexible as your organization needs it to be. This Program Increment. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.

A portfolio is a collection of these programs, the total amount of budget dollars within IT going into software development. SAFe calls this Program Portfolio Management, and suggests that one office has the responsibility for strategy and investment funding, program management and funding. A Rally Software Blog lists 40 things you need to know about SAFe.

Let’s get to work as a team and jump on the release train

Each release train (remember, that’s 50–125 people) meets once at the beginning of each release cycle to develop Program Increment Objectives, and the team-level objectives that make the increment objectives possible. The meeting is typically two days long. In addition to simply planning, the meeting has other benefits, like allowing the team to have a sense of team-ness – to create the face-to-face conversations that make real progress possible. The meeting includes representatives from both business and technology; over the course of the event, the two groups merge and align, again reducing friction and errors from misunderstanding.

After planning, the team works on the next Program Increment, and a small team needs to steer or coordinate that work to success. SAFe calls that the release management team, which typically consists of the Release Train Engineer (a program facilitator, chief scrum master for the train), Product Management, and a few executives who are not committed to that program full-time. It may also include development managers, senior testers, architects and other roles on the program that could give input. This is the group that communicates with external groups on timing and takes corrective action when there are schedule problems. SAFe suggests that the group meets weekly.

To avoid crappy code, SAFe suggests a handful of practices that are aimed more at prevention than traditional test/fit testing. SAFe starts with Agile Architecture, a principal that architecture is emergent, but the system architecture needs to evolve ahead of the newest features, to make adding those features possible. It includes continuous integration, having the software build and automated checks run for every check-in. SAFe advocates test-first as a philosophy, not just unit tests but also at the specification level. This practice of creating concrete examples, down to the inputs and expected results as a collaborative, whole team effort is called Acceptance Test Driven Development in SAFe.

SAFe also includes classic eXtreme Programming practices like pair work, not just for programmers but for many roles, along with refactoring (improving the design of existing code) and collective ownership. Collective ownership of code gets more complex with multiple teams, but it also means that teams can make corrections instead of creating a “ticket,” or “make-work” for another team. This prevents the first team from being blocked and also does not create priority problems for team two – as team one’s priority and blocker will probably be team two’s “nice to have.”

SAFe at portfolio level

At the portfolio level, SAFe looks for the IT organization ability to deliver, and perhaps support/maintain, working software. The metrics that SAFe suggests are things like employee engagement, customer satisfaction (these may be internal), agility, time-to-market, quality and the ability to work with partners outside of the software organization. In addition to these measures, SAFe suggests burn-up charts to manage the process of an individual epic and a bar chart showing actual and to-be-done work to compare the progress of multiple epics at one time.

Where most agile development organizations focus at the team level, on sprints or iteration, SAFe focuses on the program, which could be five to 15 teams. The program-level sprint in SAFe is the Program Increment, formerly known as the Potentially Shippable Increment.

Now we start to see the pieces of SAFe coming together: Release Planning defines the objectives for the Agile Release Train, which are built during the Program Increment.

Again: is SAFe evil?

In his 2013 blog post UnSAFe at any Speed, Scrum founder Ken Schwaber argues that SAFe is essentially the Rational Unified Process (RUP) rebranded as agile and that after the failure of IBM’s RUP in the marketplace, the RUP people came to agile. Dean Leffingwell, the lead author of SAFe, was a senior vice president at Rational Software Corporation (now a division of IBM), and many of the contributors to SAFe do have a Rational or IBM background. One highly-placed source suggested that where the Agile Software Movement came out of practice, RUP, SAFe, and other methods were derived theory-first, not out of what has worked, but instead on what should work, based on models. So far Schwaber’s position.

Reading the SAFe descriptions, however, gives a different impression. Most of the pieces of SAFe are familiar, borrowed from existing agile methods that work like Scrum, XP, and Kanban. The argument that SAFe derives from theory has less credence than the argument that SAFe is a transitional point sold as the end goal.

Is SAFe evil? It depends. If your organization benefits from a ‘follow the rules’ approach, SAFe is valuable. If your process maturity is more on an ‘adapt the rules’ or ‘ignore the rules’ level, then implement a more light-weight, non-descriptive framework. SAFe may be a good, transitional step. After that, the organization needs to figure out what improvement should happen next, and that requires context. Agile coach Yves Hanoulle puts it this way “For most of these I would say, SAFe goes further as they are ready to go, not far enough as they should go.”