In the first part of our article we looked at the first three deadly sins of a presentation: not defining a goal, looking at your presentation as a PPT document and lack of structure in your presentation. Let’s now look at the last four.
I often deal with various presentations, both as a consultant helping to prepare them as well as a member of the audience. And I have come to the conclusion that the ability to prepare and deliver presentations does not depend on your position in the company, whether you are a manager or a rank-and-file employee, an analyst working with the customer or a team lead working.
In the first part of our article we looked at what a backlog is and how we can apply grooming to it in order to make sure that our goals always stay relevant. Let’s continue our discussion on this subject.
In our previous articles about Agile Life Planning we talked about how to determine a set of life goals, and make a list of objectives and steps to achieve them. This article deals with the next stage of Agile Life Planning. Its purpose is to ensure a regular revision of that list, constantly updating the backlog of goals and objectives.
If the title made you a bit scared we mean that in a good way. Last week Luxoft Training took part in Business Summit for HR, one of the most important events in Bucharest dedicated to HR professionals, both specialists and managers.
In our first article we looked at how we can identify some of the challenges that arise when creating architectural diagrams – from color to mixing runtime and static elements to diagrams that might be too cluttered. Now let’s look at the guidelines we need to have in mind.
At some point in time, in every software project we are involved in, there might be a need to create architectural diagrams. Whether we are following a formal architectural model (e.g. Kruchten 4+1, Rozanski & Woods, etc) or not, there is a need to document some parts of the application by creating diagrams. In software architecture, such diagrams are created in compliance with views which are related to a specific viewpoint that could be part of a model, but in the current article I prefer to stick to the term architectural diagram and not be very formal; all the other aspects are not intended to be covered here.
Every year Bucharest plays host to one of the most important IT&C events in Eastern Europe. Internet & Mobile World aims to build an important framework in Romanian industry for learning, networking and new business generation that reunites a B2B audience in an environment designed for sharing digital, mobile or IT software & infrastructure solutions for their businesses.
In the first part of our article we talked about goals and how to divide them based on whether we want an eventual outcome or a permanent result or effect. Now we will look at goal decomposition.
We’ve already discussed in a previous article how you can make up a list of your goals and why it is necessary. Now let us see how you can further handle that list. The first thing we have to consider is that we can’t just start working in accordance with such high-level list of goals, moving from one goal to next. If you were making your list by using and combining different methods of defining goals, then it would probably become rather eclectic; the points of such a plan could (and should) be very different from one another.
