Lego Serious Play

Do you know what the term Lego Serious Paly really is? Or how you can get started with Lego Serious play? Well, if you do not about this term and want to learn, then keep reading this article.

Lego Serious Play is a special methodology in the agile world. The Lego Group created this methodology and made it available under the open source which is a model of community-based. The goal is to be a creative thinker by using Lego bricks. Big companies use Lego Serious Play methodology to enhance their business performance through the imaginary scenarios by constructing Legos in three dimensions. Now let’s get started with this methodology.

All you need is some Lego bricks. There are multiple colors and set options to choose from.  Go to Lego meetups or organized one of your own. In these meetups, a question will be given to all attendants and each one of them will answer it by using Lego bricks. In the end, a single model will be built as a team in order to represent the understanding of the respected problem. After this action and decisions would be taken. In big organizations and companies, employs the use of Legos to represent their work with confidence and commitment.

By using Lego Serious Play one can explore connections and relationships between people and their world. Lego Serious Play guides you in an honest and freely opinion’s exchange. The tangible and physical construction will allow you to make conversation without fearing of treading upon some kind of personal feelings. This way real issues will get addressed and other people will also get a chance to see the problem with their eyes. Lego Serious play allows you to take a shortcut toward the core. Lego bricks work as a catalyst and when you will use it for metaphor’s building, the processes would be the trigger that you might not previously aware of.

Sources

  1. https://www.lego.com/en-us/seriousplay
  2. https://www.lego.com/en-us/seriousplay/the-method
  3. https://en.wikipedia.org/wiki/Lego_Serious_Play

— Slimane Zouggari

Popcorn flow

Around the year 2000 a new method of getting things done fast and easy was produced it was called Agile software management(IT). This was used to make groups of individuals make fast and quick decisions while continuously learning and adapting at the same time due to this method many businesses and organizations quickly adapted this approach and implemented it within their respective regimes.

However even though this was initially a success certain problems started to boil to the surface. Many teams would get stumped on certain problems and the team management would break down this occurred due to the lack of proper management and a very strict chain of command the higher ups would let the managers make all the rulers and the workers who actually had to do the job would getting fumbled and the smooth machine of a working industry would break down for this very reason a smart individual decided that change had to be brought into the works and hence he came up with POPCORN flow.

How does it work?

Popcorn flow essentially works like a fast-acting virus where teams adapt to the nature of the business and evolve along the way the concept is a small team will evolve and adapt far quicker than a huge team. Essentially popcorn flow is based on three principles. They are that one must adapt quickly, everyone must share their opinion so that the common opinion becomes fact and then they must learn as fast as well. A typical team will look at problems, find the possible options, experiment with those options commit to one then work with it review the answers and move on two the next issue. This quick and fast-moving process is how popcorn flow works. It is a fast-adaptive method that gets things done efficiently and on time.

— Slimane Zouggari

Programmer Anarchy

For the knowledge of people, Programmer Anarchy is another concept that is related to Agile. It serves as a post-Agile that’s coined by Fred George. Programmer Anarchy says that the development of software is more profound and have more chance to get success when the programmer who’s doing the job is self-organized.

The concept of what to develop manager is less environment where the programmer can still survive without the aid of the manager or the head. Programmer anarchy want to changes the professionalism and involvement of the manager of the team and the programmer takes the responsibility for the fall and success of the project. The author of programmer anarchy wants the developer to be manager less with every project that they do.

When to use Programmer Anarchy?

Program anarchy is the process of developing a product such as application with manager less and instead, they are the one who stands between the clients and the work force. You use the concept of Programmer anarchy when you are on a project, which your team does not need to have a manager that will represent you. You can observe the criteria of the agile team that works hard to meet the deadline, but the difference here is there no other professions that will serve as the manager.

When not to use Programmer Anarchy?

Programmer anarchy gives many benefits for the developers. There is still the presence of commitment needed. Since that, you do not have the manager who will give you the deadline; you are the one to motivate yourself. Most of the developers that cling to the idea are more devoted to finishing the project than the average. If you do not have the gusto to bring all your effort, better stick to the agile way.

Concrete examples of Programmer Anarchy

The author says that the manager has the power to take action and direct it to whom the developer team is. Let us say that the manager want you to rewrite the agile story and repeat the process using .NET and SQL Server. As a developer, you think that it was already written well but the manager insisted that you rewrite it. The manager can be tricky at times because they really do not change the story and makes the effort of the developer go to waste.

Criticisms about Programmer Anarchy   

Shifting to programmer anarchy can be a waterfall because of the shifting of the development team and the customers. It says that agile development manager less can be difficult for the programmer to handle and take the full responsibility. They say that programmer without managers can be stressful for the part of the developer. However, many developers switch to programmer anarchy and happy with the result that they experience.

Even though that programmer anarchy limit or do not buy the idea of manager based team, they still have the presence of agile manifesto compliant. Such as interaction with the process and the tool use, the working software present in the agile thing, collaboration with the customers, and the immediate changes to the plan. Overall, there is the agile way with manager less concept.

— Slimane Zouggari

eXtreme Programming

Extreme Programming: What is it and basic principles?
Extreme programming is an agile development methodology that is primarily aimed at increasing productivity when developing a software project. Priority to jobs that give a direct result and in which the bureaucracy that may exist in the work environment is reduced.
BASIC PRINCIPLES
We have 12 basic principles that are grouped into 4 different categories:
• Feedback.
• Continuous process rather than blocks.
• Shared intellectual property.
• Shared understanding.
FEEDBACK
Test principle: the first thing you should do is set a period of acceptance testing program, in which the inputs and outputs of the system will be defined. Basically it defines what should the software developed. As if it was a black box.
Planning: The clients (or his representative) write needs to define precisely the activities that the system must perform. At this stage a document containing user stories that form the release plan, which defines the delivery time of the application in order to receive feedback from the client will be created.
In-situ client: the client (or his representative) should be part of the development team. You will be given the power to determine the requirements of the application define the functionality and prioritize certain things. Thanks to this, there will be a strong interaction with programmers, thus reducing communication time and the amount of documentation to write. The customer will be with the team throughout the project development process.
Pair-programming: These points with the above are the most radical of this methodology. It is to write code in pairs sharing a single machine. According to the experiments already carried out on this method, better and more consistent applications at equal or lower cost occur.
ONGOING PROCESS IN LIEU OF BLOCK
Continuous integration: is gradually implementing new software features. Instead of creating stable versions according to a schedule previously performed, programmers meet your code and rebuild the project several times a day if necessary.
Refactoring: by constantly removing duplicate code and / or inefficient programming teams improve the system design. The code is continuously evaluated to provide the highest possible quality.
Small deliveries: the product is tested in a real environment by placing a simple production system which will be updated quickly, ie, every 2 weeks (maximum 3) the software will be put into production.

SHARED UNDERSTANDING
Simple design: the best program is one that meets the requirements and simpler. It is important to provide software that meets the needs of a client. No more no less.
Metaphor: expresses the evolutionary view of the project and defines the objectives of the system through a story.
Collective ownership of code: the code has shared ownership. Nobody owns anything, even what he has developed. All programmers are “owners” of all the code. According to this methodology, the more programmers is working on a piece of code, fewer errors will.
Programming standard defines the rules for writing and documenting code, and how the different pieces of code developed by different teams communicate. The aim of this is that it seems that the code has been written by a single person.

–Slimane Zouggari

SAFe

SAFe presents a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis
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 (more on that below). 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.
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 have the responsibility for strategy and investment funding, program management and funding.
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 (PI) is described in more detail below. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.

The Scaled Agile Framework, or SAFe, provides a recipe for adopting Agile at enterprise scale. It is illustrated in the big picture.
As Scrum is to the Agile team, SAFe is to the Agile enterprise.
SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale. It is field-tested and enterprise-friendly.
SAFe is the brainchild of Dean Leffingwell.
SAFe is based on Lean and Agile principles.
There are three levels in SAFe:
* Team
* Program
* Portfolio
SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program.
The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization.
SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries.
Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI.
PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
New program level roles are defined
* System Team
* Product Manager
* System Architect
* Release Train Engineer (RTE)
* UX and Shared Resources (e.g., security, DBA)
* Release Management Team
In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.

–Slimane Zouggari

What is Agile Software Development

Agile software development is a set of principles that portrays certain requirements for software development. It comprises of solutions that evolve better through self-organizing and cross functional teams. The principles are aimed at promoting adaptive planning, early delivery, and constant improvement, and it also encourages flexible and speedy response to change. Agile was first introduced in the 1980s when the idea of technology and technological advances took off in the Western world and has since then undergone a number of significant changes. It doesn’t consist out of any specific methods, but rather a range to choose from.
Before these methods are discussed, it is important to note that in 2001 the official Agile Manifesto had been drawn up which exemplifies the certain goals and requirements of agile software development. It consists out of the 12 principles of agile software development that keeps its developers on the right track. These also influence the different methods which will now be discussed in short.
Waterfall
The waterfall model is more of a philosophy than it is an actual method in which the mind-set is aimed at the project. It is usually in direct contrast of the iterative approach due to their complexities and differences when opposed to each other. The main differences between these two are the ways in which the software is built and tested. The waterfall method comprises of a separate building and testing phase, whereas in iterative methods the development testing is done concurrently as it usually is done in programming. Both these methods deliver desirable results. As soon as the developer has more knowledge about the software’s functions and values, they can make more informed choices. This is especially important when it comes to scrum as this kind of software development only has an iteration of 2 weeks.
DSDM
Another method that can be used is the dynamic systems development method (DSDM) which acts as a project delivery framework. This forms part of an iterative approach and embraces user involvement. This type of development has the ability to fix costs, quality, and time at the outset. It categorizes the do’s and don’ts so carefully that it has become the number 1 method of agile software development. The DSDM method also underpins 8 important principles that developers should and can follow when they are busy with such a method in order to produce effective results.
Kanban
This method is more focussed at the development team than it is on the actual product and process it is working on. It is very beneficial when it comes to agile software development, because it boosts team productivity. In this approach, team members are placed within a full view of the project and each person has an assigned task to complete. Participants work in a queue where delivery time is shortened and the product is completed more effectively. In terms of agile software development it is effective in working as a visual process-management system in the sense that it shows the team what to do.

–Slimane Zouggari

DSDM: Dynamic Systems Development Method

The purpose of DSDM is to provide systems faster than is achievable in the waterfall approach without compromising on quality and development. The main control means is the time box: a short period of time (days or weeks) within the project, in which a product is delivered according to agreed quality.
Since the early 90s, there are new types of system development methodologies which is as a result of the fact that the old methods is often referred to collectively as waterfall methods, which has failed in yielding what was expected of it.
DSDM
Dynamic Systems Development Method. DSDM was developed by the British DSDM Consortium.
The objective of the DSDM Consortium is making it a publicly accessible and generally accepted method, regardless of technical tools. It focuses on the information needs of a company and the solutions to be delivered, and as quickly and cheap as possible. DSDM is trying to fill that approach to building and maintaining systems that meet a tight schedule at a manageable project.
Based on a large number of projects the below advantages can be cited:
• The system is built faster;
• The users are more willing to take the system in-house;
• The risk of building an unusable system is reduced;
• The final system meets usually better to the business requirements of users;
• The users are better educated;
• The introduction of the system is usually smoother.

–Slimane Zouggari